Slashdot Mirror
Could Graphics Drivers be Included on the Card?
starseeker asks: "With all of the difficulties (both technical and legal) caused by binary graphics card drivers (e.g. the nVidia drivers) the question naturally arises - why is it necessary to have all of this logic at the 'kernel' level in the first place? Why couldn't the necessary logic be abstracted on-board the nVidia/ATI/etc card and just have the OS use one generic driver to access the functionality in all of them? Use OpenGL or similar standards on the software side, and have the card handle things on-board from that point on down? That way, hardware manufacturers wouldn't have to listen to all the flack about binary drivers, and Linux users don't have to suffer with second-rate graphics and/or deal with binary drivers in an open (and dynamic) environment. Are there technical reasons this isn't practical? Or is it simply that it's easier/cheaper to do that type of work in the OS?" There are several issues that currently make such a thing impractical, but the large hurdle at this point is that there doesn't seem to be any interest (neither commercially or technically) to make such a leap.
I think for this to work (good idea) it would require a comapny like MS to "play ball", and they won't. It is to their benefit if the HARDWARE can't just work out of the box on ANY OS. Imagine if any card could just work on linux and OSX? Then this spread to TV cards, and all other hardware devices.... Windows has a monoply because most software and hardware is made for WINDOWS, and I don't see MS giving that up so easily...
Run gigabit Ethernet from the computer to the monitor. Have the "monitor" be an X terminal that speaks X11 protocol. There, problem solved, and you can even put the computer in the server room or garage.
Windows still doesn't speak X11 or even VNC.
Welcome to two decades ago.
Tom
Someday, I'll have a real sig.
It's called an API, and it's not a new concept. There may be a different term when it's hardware-software as opposed to software-middleware, but there it is.
You build your hardware always such that the newer ones understand the older instructions, just using supersets. Unfortunately it means every X years you have to start from scratch to get rid of the absurd backwards "if such and such then do this kludge".
But it's a good concept. If published, it allows for open drivers (or whatever), as long as you know "when I put bits in here, this is what it does with them, and the application is going to give me the bits in such and such order", you can figure it out (well, I mean, I can't and YOU may not be able to, but someone can).
sig?
Read my tagline.. now re-read it. If we could do away with drivers, we would have done so long ago because there is no greater pain than having idiot users complain about drivers, call tech support because their drivers are corrupt because their OS is an infested pool of shite, or whine about how your expensive gadget doesn't work on their exotic "look what I made" OS derivative. Trust me, if all hardware companies could get rid of the software part of their product, they'd do it in a heartbeat. They can't.
What does a network driver do ? It takes your data, slices it into packet-sized chunks, adds error protection/recovery, keeps tabs on what's going where and how much, then gives you a shout whenever it's done or wants more data. It does this through a mostly standardized interface, but each network device has its peculiarities and unique features. The drivers are what presents these varieties in a consistent way to whatever software or OS wants to play with them.
If you want an example of what we did before drivers were "in", look ten years ago with sound cards. You never knew if a game that supported "Sound Blaster" would work properly on your "Sound Blaster Pro".. much less on your "Sound Blaster 16". Why the hell not ? All three are capable of digitized sound and FM synthesis, so why does the game that runs on the grainy, 8bit mono 22khz SB not work on the 16bit stereo 44khz SB16 ? Because it was coded directly to the original hardware with no indirection whatsoever. How bad was it ? We actually had Sound Blaster emulators for the Sound Blaster AWE64, that were essentially device drivers that presented an SB1 interface and translated those accesses into AWE64 functions.
Feigning ignorance for a moment, let's pretend all sound cards could present a consistent interface no matter what the brand or model was. We'd still need a "universal driver" to manage our sound, right ? Something like DirectX, or OpenAL, or ALSA, or ESound..... whatever you call it, we'd still have some means to pander to our laziness as programmers.
As much as I'd like to see an operating system that can "figure stuff out" on its own, it's just not gonna happen in this decade. It would require close collaboration between software developers and hardware designers.. collaboration usually means a governing body that charges fees for certification, a governing body means something that can be manipulated to favor the interests of whoever has the most money to throw around. From that perspective, it is a doomed concept.
Now if something like the Linux community could come up with open-source hardware type stuff.. like a standard for sound cards, video cards, TV tuners.. and enough friendly supporters to manufacture compliant devices and fully commit to the cause, maybe over time we could see a transition if the project turns out beneficial to all parties involved. No drivers means no need to pay a cocky driver developer team the big bucks.. no more "I need a network driver but I can't get on the net" chicken-and-egg bullshit.. no more Billco having to hold some redneck's hand while I have them reinstall the drivers on their X-brand-name spyware-infested PC. Yeah it would be sweet! But it would take a big commitment from everyone.
-Billco, Fnarg.com