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.
Basically, you're asking for the software interface of the hardware to be standardized and abstracted. In a nut shell, hardware is expensive and software is cheap. Anything you can do in software with little or no impact on your performance requirements is something you should not do in hardware. ATI and nVidia have radically different approaches to GPU design. With differing internal structures, the interfaces exposed to drivers is also going to be radically different, but there's no reason not to use cheap CPU cycles to create the abstraction rather than expensive logic gates in hardware.
Hardware is expensive because the cost of a chip goes up roughtly with the fourth power of the logic area.
IMHO, the best solution to the problem of drivers for Linux is simply to not buy hardware that doesn't have open source drivers. Do you think that makes life difficult? The Open Graphics Project has opinions about that.
No, it is a terrible idea. The right way is to release the specs to the damn hardware. CPU manufacturers do it, why not video cards ?
We already have driver built in the video card. It is called VIDEO BIOS. The latest VESA specification allows for fancy things like requesting memory map of the framebuffer so one can have direct video access. It is easy to envision making a specs for 3d acceleration as well. It could even be in pseudocode - one could compile the driver to whatever hardware is using it.
So why this does not work ? Because, aside from graphics companies making shitty BIOS to begin with, companies like Dell intentionally cut down BIOS to safe a couple of dollars on flash RAM. Ask yourself - when was the last time you saw a widescreen laptop which video BIOS knew how to setup the widescreen mode ? And this is one of the most basic things.
Good and thorough description of the hardware is a requirement for doing interesting things with it.
EFI is what you are talking aboutI nterface
http://en.wikipedia.org/wiki/Extensible_Firmware_
Ahem...
...and your point was?
ATI Linux Page
nVidia Linux Page
IBM Linux Drivers (for a random chipset)
VIA Linux Drivers (for a random chipset)
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
ISTR the NuBus had this capability. Cards had the drivers on them, and they identified themselves to the bus, so when scanning the bus for hardware you just got "graphics card in slot N". They all presented the same API, with bus NAKs or soemthing if the software requested a mode the card didn't support.
This, of course, made changing features a bitch, since you couldn't tell the software that you had eight hardware shaders instead of one, because there wasn't space in the API data structure for that...
Just junk food for thought...
That's a really good question. I'm not sure I can answer it, but I'll give it a shot.
The CPU does very primitive things. It adds, subtracts, multiplies, divides, loads memory into registers, and stores registers into memory.
The program's interface to the GPU is at a relatively high level. First, the program sets the GPU's render states. The program sets things like which textures to use, is alpha blending enabled or disabled, which shaders to use etc.... Then tells the GPU to draw some triangles. The driver gets to decide the best way to deal with these requests.
For example: the program may tell the GPU to use a certain pixel shader. The driver can use what it knows about the current render states to decide if the shader is performing instructions that don't matter (for example: calculating the alpha value even though alpha blending is disabled). I don't know if drivers _do_ this, but they could. At the least, the shader program is written in the generic D3D, or OpenGL language. The specific GPU installed may support fancy features (like the capability of performing two dot products in a single instruction). The driver can recompile the shaders to more closely match the capabilities of the actual GPU.
I guess it boils down to the abstraction layer. The CPU instruction set is a very low-level abstraction, the D3D/OpenGL interface is very high level.
USB keyboards and mice, and probably other stuff, had a spec since the mid-90s... pre-windows 98. I had motherboards in 97 with USB that never quite worked correctly because MS wanted different drivers than the spec built into the boards. So yes, the MS monopoly clearly held back proper adoption, maybe not thru malice, but thru laziness. I've found MS plays the "techincal difficulty" card quite well over the years. They're a company with more money than god, and some of the best programers in the world.. if they don't do something correctly the first time it's ALWAYS on purpose...neglect or malice... never forget that.
OpenBoot (IEEE-1275) has been doing this 15+ years. The drivers are in the firmware of the card in FCode, which is a variety of Forth. Sun, IBM, and Apple have been shipping systems for years. All the machine has to do is load the FCode and you were off. If the OpenBoot environment could see the device tree, you could boot with it and use most of the functionality.
Main catch is that it made the card bigger/more expensive - important especially when you look at some of today's tiny cards. In this age of the internet we're probably better off just working off the unique PCI ID that every card type has. The ideal would just be a little utility that scans the IDs and fetches (or tells you) what you need. MS has done a half-assed job of it with Windows Update, but it definitely could be better.