Re-Introducing GEM-Free UMS Support In The Intel Driver
Phoronix: Re-Introducing GEM-Free UMS Support In The Intel Driver
It seems like it was just yesterday, but Intel introduced the Graphics Execution Manager more than two years after they had a falling out with TTM. In switching over to using GEM for their in-kernel video memory management, and subsequently supporting kernel mode-setting and then introducing UXA to GEM-ify the EXA 2D acceleration architecture, there was a lot of problems. Fortunately, most of these problems were worked out as this more advanced Intel Linux driver stack matured and for the better part of a year now the experience has been pleasant for users of most Intel GMA chipsets...
I had several computers with 810 graphics chips in the motherboards, however they have all failed and I put in old geforces. But in even more recent history they have been relegated to the storage room as I've been able to get free computers from 2004 era to replace the 1999 era ones. In those I am using geforce 8400gs's which give them gaming and 1080p with vdpau the original PCI 8400gs version is amazing and weird for this. The intel chips in those computers don't have even DVI out, so were talking low res, old motherboard crt users here right? and folks wanting to use the most recent linux versions rather than some slackware installed in 2005?
But hey this code will be usefull 1000 years from now when folks want to emulate these old 8xx chips and all. I understand not wanting to have 'working' hardware, not be working in the latest software... but I wonder, since I have seen so many mobo's with these chips partial fail (mobo works, gfx dont, but pci gfx do). I will keep track for the rest of my life when the 8xx chipset dies out simply from failure, rather than lack of 8xx hardware around or driver support, now that were guaranteeing it.
[QUOTE=oneman;138334The intel chips in those computers don't have even DVI out, so were talking low res, old motherboard crt users here right? and folks wanting to use the most recent linux versions rather than some slackware installed in 2005?[/QUOTE]
Well the 855GME was still being sold in computers in 2006 so not everyone who needs an 8xx driver is running some old motherboard...
(that being said, as long as I'm not doing 3d the driver seems to largely work for me... haven't tried the lastest driver yet though to see if it resolves those issues)
Right now AMD open source support seems better to me than Intels, because I'm unable to upgrade my graphics drivers due to various serious bugs in the driver versions newer than 2.9 random hard lockups, one with freezing in flash ......
I don't think it would cost them so much to make better drivers (e.g. hiring one or two more developers), intel is 20 times bigger than AMD in revenue and their graphics doesn't have soo many awesome features doesn't it?!
don't get me wrong it could be worse, at least I've got reliable working drivers right now .... but that doesn't mean the current situation is good in any way.
I don't get it. Is there some actual technical reason that those old chips can't have a good, stable KMS/GEM/DRI2 driver? I sure don't know of such a reason.
Because that requires work?
I guess it was easier for Intel to get working drivers by re-enabling some legacy features.
Mode setting is a huge PITA. Especially with older Intel stuff. Each mainboard manufacturer was free to set up whatever crazy scheme for modesetting that they felt like. There was very little standardization so it was always a huge PITA for anybody to support.
I know that with a old 'Extreme Blaster' laptop I had I could not use the native LCD support because Xorg and Linux had no support for the model-specific modesetting scheme. I could only use VESA standard settings that were pre-loaded into the BIOS.
I guess the user space modesetting stuff has a lot of work arounds and tested code for doing modesetting on each and every little bizzare crappy motherboard that Linux supports and nobody wants to bother porting all that shitty code into KMS.
Intel probably had some OEM crying to them about Redhat 6 support on their server hardware or embedded device or something like that and this is Intel's way to give them something that works while they get ready to drop 8xx support altogether in a year or so.