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.

Comments

It seems to me that all the hardware

[iminplaya]

should the drivers built in. It would definitely shorten boot up time. The present method is such a kludge. I don't understand why it happened that way in the first place. Now if I can only get a car that includes the driver...

Re:It seems to me that all the hardware

[squiggleslash]

That's what the Amiga did. Autoconfig included ROMs whose libraries and devices would be added to the system upon boot. Come to think of it, my old Sinclair QL also supported ROM OS extensions on each expansion card. It was pretty normal in the 1980s for non-PC computers to work this way.

Much as it helped give you an out-of-the-box "it just works" experience, it was flawed for a number of reasons. First, these things are, by necessity, operating system specific, unless you really want to dictate the architecture of every operating system. AmigaOS users found it useful, but those running MINIX or even AmigaUNIX were out of luck. You can probably find a way to build something akin to NDIS style wrappers, but that does mean either significant architectural or performance compromises need to be made in terms of how your other OSes work.

Note that this even applies to "cross platform" solutions like OpenFirmware. OF uses FORTH-based bytecode device drivers, and yes, display cards are part of that.

The other major problem is that the device drivers tend to be whatever was current went you put the device in a box and shipped it. As hardware manufacturers seem to be relatively incompetent when it comes to creating device drivers, it's hard to see how that's a bonus. The author is talking about ATI sticking OpenGL on their cards. Has you use4 fglrx? The most recent version is the first moderately reliable implementation I've seen (that is, it's been running for a few days now on my laptop without any kernel warnings about NMIs), and the previous version, apparently, was the first to support my graphics card (an X1300), six months after the X1300's launch.

ATI isn't the only vendor that appears to be utterly clueless when creating device drivers. Microsoft actually gave up and generally ships its own in-house drivers for everything it knows about out of the box. Most GNU/Linux users will tell you that their systems are generally stable unless they are obliged to include some binary blob based driver, or just an "independent" project maintained and written by a hardware vendor due to some licensing issue.

The bottom line is that expansion-card based device drivers just aren't dynamic enough.

MS won't play ball...

[CDPatten]

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...

Re:MS won't play ball...

[SanityInAnarchy]

I think for this to work (good idea) it would require a comapny like MS to "play ball"

Like hell it would.

USB keychain drives are a pefect example. On Win98, you need driver software, but on any recent Mac, Windows, or Linux, just plug it in and it works. I have, in fact, NEVER had a bit of USB Mass Storage not work out of the box on Linux. True, it's not as standardized as we like -- uhci vs ohci, for instance -- but it's getting better, there's only one ehci.

No, all this needs is a working implementation with a killer feature, so it becomes so insanely obvious that it's the right way to go that MS either complies on its own, or consumers bitch loudly at them and threaten to Switch, and then MS complies.

How do you explain the USB situation, otherwise? And keychain drives aren't all -- hard drives also work -- hell, any USB keyboard/mouse should work out of the box as a USB HID -- that means exactly one driver for "usb mice" and one for "usb keyboards".

I guess what it really needs is to be more clearly defined and to be economical. For instance, having the "universal driver" be something loaded off Flash and into the OS would not work, especially when we're talking about 64-bit.

So the real reasons are most likely technical, and not "MS is a monopoly."

Re:MS won't play ball...

[sco08y]

>I think for this to work (good idea) it would require a comapny like MS to "play ball"

Like hell it would.

USB keychain drives are a pefect example. ...

How do you explain the USB situation, otherwise?

Apologies for taking the sports metaphor further, but with USB MS *dropped* the ball. Apple made USB standard on their machines so device manufacturers were making USB devices that worked on Macs. MS had to play catch up. Now that there are tons of devices on the market, it's too late to screw with the standard.

I still remember ordering a USB hub and getting the Mac user treatment when I was asking about the specs...

Re:MS won't play ball...

[mabhatter654]

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.

Patch vs Flash

[lexarius]

Driver patches happen. If the driver is in hardware, you'll have to flash it, which has somewhat more severe consequences in the event of an error.

NVidia is partway there

[Dasher42]

I think NVidia is doing something right in this department. The same video driver works across the majority of their cards, from the old TNT2 to the latest GeForce. This implies that a good level of abstraction is possible with video cards, and if this is the case with video cards, one wonders how much can be done with other hardware.

Re:NVidia is partway there

[zerocool^]

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).

shouldn't even need a card

[r00t]

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.

VESA F'ING BIOS

[tomstdenis]

Welcome to two decades ago.

Tom

Simple: Hardware is expensive

[Theovon]

Note: I'm a graphics chip designer.

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.

I've got a different question:

[Ant P.]

Why do GPUs need huge drivers when CPUs don't?

Re:I've got a different question:

[contrar1an]

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.

Re:I've got a different question:

[Surt]

Why do GPUs need huge drivers when CPUs don't?

CPUs have this enormous driver called the operating system.

Re:I've got a different question:

[Jeff DeMaagd]

That's a pretty good point. All compiled software is given at least some basic information about the target CPU and tunes for that CPU. Also, because AMD and Intel start from the same basic instruction sets, the compiled software will generally work on both.

ATI and nVidia don't start with the same instruction sets so they need their own software to convert the high level graphics calls to their own chips.

Re:Make it flashable?

[Ruie]

I think it's a good idea. All of the problems that immediately jump out at me-- things getting outdated and such-- would seem to be dealt with very easily by making the internal software updatable, some simple solid-state memory.

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

[Joe The Dragon]

EFI is what you are talking about
http://en.wikipedia.org/wiki/Extensible_Firmware_I nterface

Re:Another way to open drivers

[radish]

Ahem...

ATI Linux Page
nVidia Linux Page
IBM Linux Drivers (for a random chipset)
VIA Linux Drivers (for a random chipset)

...and your point was?

TI / Apple had this

[Doctor Memory]

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...

Acorn's RISC OS machines did this too

[MadAndy]

They used to have a ROM chip on the board. Deviced drivers came in the form of 'modules' - and one specific to the device would be loaded off its ROM chip. If you had a newer driver, you'd load it from disk and it would replace the ROM one. It meant that the hardware worked 'out of the box', but if you needed newer drivers you could still use them.

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.

Yes&No&Why can't I have Openfirmware in my

[gd23ka]

If what you're thinking of is a fully fledged performing 3D Driver then I'm not sure that's a possiblity
because that graphic card has to work potentially with a lot of Operating Systems and CPU architectures,
because that card might get plugged into anything from a Power/AIX machine to a SPARC/Solaris with
Intel/Microcrap in between. However there is a completely platform agnostic way to get a video card set
up so and that is OpenFirmware (Openbootprom) IEEE 12something. Openfirmware cards (SCSI, FC adapters
readily come to mind) have a prom on them that contains F-CODE (tokenized Forth is what it is) that the
interpreter in the Openfirmware can run to get a card setup and perform basic operations with it. So
if that's what you need, we already got that working on real machines and now would be the time to forget
all about Intel's EFI boot environment crap and get a real firmware even for your PC.

If however you're thinking of a card whose sole purpose is to run this quarters first person shooter with a
l33t number of frames per second on your PC at home, then I think they might get away with some sort of binary
driver mapped into memory somewhere and generic Windows driver bindings to work with that. A couple of things
that are pretty Windows-specific come to mind however:

a.) the graphics driver vendor can easily install spyware into your system you can not easily get rid off anymore. Don't laugh.
Even Microsoft is doing it as we just recently learned and they'll probably be more than glad to sell that
privilege to your card vendor too.

b.) Unless it's flasheable that code might be exploitable

c.) If it's buggy as hell (and it's gotta be because you only paid $400 for it, cheap skate) it better be flashable
or you'll have to get the card replaced (better refunded)

d.) Microsoft might not be happy with that solution because Linux on Intel will have it just a little bit too easy for their taste.

All who aren't driver/kernel developers shut up

[billcopc]

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.

Re:Make it flashable?

[ebonkyre]

Heck, stick a jumper on there that clears the memory and resets to factory defaults.

Are you kidding? Those jumpers cost two cents each...

By the time it makes it past the lawyers (are jumpers patented?), engineering (DIP switches are cooler, man), QA (Oh, you wanted them soldered on, too?), and marketing (Exclusive New Sleeve-and-Pin Programming Control Interface!) - the card will cost $100 more.