| |||||||||||||
This is are totally different issues...This is are totally different issues...Posted Aug 20, 2011 19:30 UTC (Sat) by BenHutchings (subscriber, #37955)In reply to: This is are totally different issues... by khim Parent article: Avoiding the OS abstraction trap
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.
(Log in to post comments)
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.
|
|||||||||||||