This is are totally different issues... [LWN.net]

This is are totally different issues...

Posted Aug 20, 2011 10:07 UTC (Sat) by khim (subscriber, #9252)
In reply to: If you tried irony then you failed. Utterly and completely. by zlynx
Parent article: Avoiding the OS abstraction trap

And for years (2004-2008) I used ndiswrapper and the WINDOWS wireless driver for my laptop because the Linux drivers either didn't work, crashed, broke suspend or changed their behavior. This seemed to vary with each kernel release.

Yup, but this period stretched for so long because "use the ndiswrapper" was standard answer and thus native drivers were poorly tested and few developers spent time fixing them. This is obvious trade-off: stable ABI makes life easier for user short-term but does not improve situation all that much long term, yet it makes life of developers miserable both short term and long term... and kernel developers rarely accept any decision which promise tiny short-term relief at the price of huge long-term pain. That's why Linux is still around and a lot of other OSes are not.

It needs dozens of developers who analyze OpenGL use by software and determine how to optimize the code.

I can't care less about "optimized code paths". The fact that all these complex and fragile compilers are in driver is madness. They don't belong there! Just like format converters for webcams don't belong there. The problems with drivers I do care about are things the driver should do: setup the videomode, handle DMA, etc. And there are two problems with these needs:
1. There are no documentation: AMD's is probably the best, Intel is slightly worse, NVidia does not have anything.
2. These sequences are changing between releases (and sometimes between steppings) for no good reason.

Note that problem #2 is significantly worse and it's brought to light entirely because Windows offers stable ABI for driver writers. This means that decisions like "save 0.01% of transistor budged and fix all the crap in drivers" look viable. This then leads to problems in both Windows and Linux, but as long as thing more-or-less works in Windows chip can be sold.

If you want to match Nvidia binary drivers, you have to do those things. It's expensive. Really expensive.

It's not hard to match NVidia driver's quality. They may offer fast 3D in games - but I don't care about that. I do care about silly things like suspend, thermal monitoring, etc - and there NVidia drivers are awful. Open-source drivers are better in this regard - but just barely, they still are awful, nothing like [currently quite stable] WiFi drivers.

(Log in to post comments)

This is are totally different issues...

Posted Aug 20, 2011 19:30 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

This means that decisions like "save 0.01% of transistor budged and fix all the crap in drivers" look viable.

The decision is more likely "don't delay tape-out to fix this hardware bug". And it has nothing to do with the ability to hide the workarounds in a proprietary driver. Like programs, all chips have bugs, and you can see workarounds for them in almost any Linux driver you care to look at.

I'm not talking about bugs...

Posted Aug 21, 2011 8:19 UTC (Sun) by khim (subscriber, #9252) [Link]

A lot of drivers contain workarounds for buggy hardware. I'm not talking about these. I'm talking about the fact that each new generation of GPU chips have totally different initialization sequences and even basic operations often require totally different driver.

AFAIK videodrivers are more-or-less unique in this regard. 802.11n WiFi card have driver almost identical to what 801.11b had - even if chip internals are wildly different. Yes, I know, GPUs are significantly more complicated... well, they are not more complicated then CPUs and these can reuse older software just fine. About the only piece of silicone comparably buggy were winmodems - and these, too, were brought to life by the promise to paper over hardware problems in software.