| |||||||||||||
This is the problem, not a solution...This is the problem, not a solution...Posted Aug 18, 2011 15:43 UTC (Thu) by khim (subscriber, #9252)In reply to: Avoiding the OS abstraction trap by fuhchee Parent article: Avoiding the OS abstraction trap
Yeah, "more crappy drivers" is real problem, and unstable ABI solves this problem quite handily, so what are the advantages? It's actually better not to have any drivers rather then have crappy drivers - not just long-term, but also a medium-term. If there are no drivers then someone will write them or hardware will just be abandoned, but crappy drivers make user's life miserable for a long, long time.
(Log in to post comments)
This is the problem, not a solution... Posted Aug 18, 2011 15:47 UTC (Thu) by Np237 (subscriber, #69585) [Link]
Of course, this is why we have such excellent drivers for wi-fi and graphics cards and the ones with crappy drivers have all been abandoned.
Wait
If you tried irony then you failed. Utterly and completely. Posted Aug 18, 2011 16:11 UTC (Thu) by khim (subscriber, #9252) [Link] WiFi is actually pretty good example. We used to have bunch of crappy WiFi drivers but they were mostly abandoned and replaced. As for videodrivers... well, the vendors decided that they absolutely, positively need to produce crap - and that's why videodrivers are crappiest drivers on all platform. I think open-source drivers eventually will fix the problem but this process is slow-going because most vendors are not just indifferent - they actively hurt these efforts.
If you tried irony then you failed. Utterly and completely. Posted Aug 19, 2011 22:06 UTC (Fri) by zlynx (subscriber, #2285) [Link]
Yeah.
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.
As for the open source video drivers, for most of them I don't believe the problem is vendors hurting the effort. AMD and Intel have been supportive. I believe the problem is just not enough resources.
It needs a massive test effort that will verify correctness in all major OpenGL applications on each card version. It needs exhaustive OpenGL test suites that exercise all the code paths. That's a hundred test machines right there.
It needs dozens of developers who analyze OpenGL use by software and determine how to optimize the code. The commercial drivers often have optimized code paths for specific applications.
If you want to match Nvidia binary drivers, you have to do those things. It's expensive. Really expensive.
This is are totally different issues... Posted Aug 20, 2011 10:07 UTC (Sat) by khim (subscriber, #9252) [Link] 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: 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.
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.
This is are totally different issues... Posted Aug 21, 2011 18:37 UTC (Sun) by Np237 (subscriber, #69585) [Link]
Yup, you point out the very problem. Once you care about speed (and at work, we do, a lot), youre basically screwed. Youre forced to buy nVidia since they are the only ones with fast Linux drivers, and you get a shitload of bugs and no support for modern desktops.
This is the problem, not a solution... Posted Aug 18, 2011 15:47 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"Yeah, "more crappy drivers" is real problem" ...
You are misparaphrasing me. Mediocre/working can be good enough for users. There exist other popular operating systems that demonstrate this quite well.
What "other popular operating systems" are you talking about? Posted Aug 18, 2011 16:26 UTC (Thu) by khim (subscriber, #9252) [Link] If you are talking about Windows then it's unmitigated disaster: drivers voodoo is huge part of that culture - and it only exist because neither users not hardware vendors can abandon this crazy platform. It's because it has a monopoly and a lot of softwate only work under window - not because it's such a fun to use. Often drivers only work for one particilar version of OS (Windows 98 or XP or whatever), and even then they are huge PITA. And all other platforms have died for the lack of drivers: such diverse OSes and Solaris, Symbian and many many others were abandoned and replaced with Linux because Linux has the most drivers available. Think Android: it's brand-new OS and we all know Google does not like GPL - yet it uses Linux, not NetBSD or something like that. Why? Because they needed "bag of drivers" and Linux was the only sane choice. Or think RIM. They have choosen to switch to QNX. Well, QNX is good OS, but it does use your favored "stable ABI" drivers model... and suprisingly enough this means it does not have as many drivers as Linux and the ones they do have are often worse. This means RIM's hardware selection is limited and that means RIM is already dead: it's question of "when", not question of "if".
|
|||||||||||||