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 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.
As a bonus, there wouldn't be any worries about ever updating drivers more than once. Reinstalling your OS? You already have the latest drivers!
Could make rolling back a bitch, though, but that should be handleable as well. Heck, stick a jumper on there that clears the memory and resets to factory defaults.
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...
What?
It would be very hard to add new hardware features if every videocard has the same driver. It could work, but only if video card tech stoped changing so much... And I don't think gamers would be too happy with that!
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...
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.
The graphics drivers could become outdated if they're included on the card. Unless this doesn't concern you, there's probably not much point to it.
Only if you want few bugfix releases and to be tied to a single high level API.
Malike Bamiyi wanted my assistance.
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.
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.
this barely even makes sense. the purpose of the driver is to provide an interface from user-level applications into the hardware. since apps. differ on a binary level between different OS', so must the driver differ between different OS'. nor is the interface at all simple; even if part of the driver were to run on the card, the card would have to have significant logic (e.g. a CPU) to run it.
That would make too much sense.
The answer here is the same as the answer to most of these "Why don't the video card makers...?" questions: The reality is that the number of Linux users concerned with high-end 3D performance and objecting to binary drivers is simply to small to be worth worrying about. As others have noted, software drivers have enormous advantages -- there's simply no economic reason to forgo them to please a handful of politicized Linux users.
What I'm listening to now on Pandora...
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 remember sitting in stupid ass Windows 95 training classes, them going on and on about how the PCI peripherals would be able to ship with their own drivers... oh well.
Is to sue the hardware makers for only releasing drivers for an OS that was an illegal monopoly.
There has to be a case there.
There's a few routes that all fit under your description.
The first and most obvious one, is an well-standardized API for using the card.
This isn't new, in fact for 2D stuff, it's ancient news. The standard is VESA VBE (video bios extensions), with it's lesser known cousin VESA VBE-AF (video bios extensions - acceleration functions). The VBE standard itself was legally free. The VBE-AF interface was only available as a commercial specification, with distribution restrictions - but copies of the information do exist.
While 2D is reasonable simple, doing a similar thing for 3D isn't trivially, because of how different cards are internally.
The major downside for manufacters is that they need to include silicon that can convert from the standardized form (say OpenGL) to what their hardware actually uses, and this raises production and development costs. If they leave out the standardized API from the silicon, and instead provide software drivers that convert from the standardized form to the internal format. When they find glitches, they can update the software much easier, and the other major advantage is that production costs are reduced (less silicon), providing better profits.
Next you might suggest a firmware based approach, similar to some of the current generations of wireless hardware. Without their firmware, they are not capable of doing anything. Internally they are generally a CPU (such as ARM or MIPS with some hardware acceleration for wireless stuff). This direct approach would prevent you from being able to see your BIOS or system firmware, as you need a system to load the firmware, and you can't install a machine without seeing what's going on. (Circular loop).
A hybrid approach might work instead:
- Existing ATI/Nvidia chips, wired to an embedded processor, with both a default boot ROM which provides a firmware containing basic 2D and character mode only, and you can upload a newer firmware with 3D support to the embedded processor.
You'd upload the 3D firmware every time you boot the system, just like present wireless gear.
In cost of parts, doing this would raise production costs $30-$50 per graphics card. Initial development would be a nasty hump as well for the large players Nvidia/ATI - because they presently just add new chips to the existing drivers, but after the initial development, things would be reasonable.
The hybrid approach has been done by one company before...
SGI! Their systems booted with basic 2D, and later pushed firmware into the graphics controllers, that allowed you to send a variant of raw OpenGL to the controller (It was a variant in that some of the complex operations had to be broken down into simpler ones).
If SGI consider selling their OpenGL IP as suggested previously on slashdot, such an approach MAY be feasible for the company that buys it.
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
Why do GPUs need huge drivers when CPUs don't?
How about an intermediate layer between the OS and the hardware that would contain all the drivers?
The operating systems would only have to deal with a standard interface independent of the hardware.
Cards would be DirectX compliant, or OpenGL compliant, then, and anything outside the scope of the standard chosen would not be possible to use.
Of course, commercially, DirectX makes more sense, although it would be a problem with ID engines, and some of the people who use these cards for actual 3d work.
CDs are way cheaper than flash memory, also, and they give you an easy way to include the last driver with your card.
Also, the NVidia utilities have to come somewhere, that's added value that they wouldn't want to lose.
Then there is the issue that some card have additional functionality, like tv out, and some special features that can be standardized for current cards, but not for whatever they want to do tomorrow.
EFI is what you are talking aboutI nterface
http://en.wikipedia.org/wiki/Extensible_Firmware_
Contrary to popular belief, just because a device uses flash memory does not mean that it cannot fail safely.
Trash an area on flash due to power failure, bad firmware image, or dried dog snot bridging the contacts of the memory chip?
No problem. The bootloader, in a protected area of flash, sees that the checksum is bad and just Does The Right Thing by loading good data from a (also protected) portion of the flash, and the device boots up to a state which may not be latest-and-greatest, or even fully functional, but is at least adequate to re-flash.
The only problem with this is that it is somewhat inefficient use of flash memory space, but the stuff is obviously far cheaper than it used to be (I'd wager that it passed "cheap enough" years ago).
Similar methods are in place in all kinds of consumer goods, including the venerable Linksys WRT54G, and generally work by allowing you to load good firmware using TFTP, even after everything has gone all wrong[2].
Just because you've had warnings about interrupted PC BIOS flashing and video game saves burned into your head, does not mean that it's all that hard to do safely.
2: And if you really hose things by killing the bootloader, you get to build a TSOP cable and, with a bit of prayer, write to the flash chip directly using a parallel port. Failing to recover a bricked WRT54G is actually hard to do, no matter how bad it gets fucked up.
Kid-proof tablet..
You would have to actually get the video card makers to AGREE on a standard, otherwise everyone is going to have their own "Kernel API" and then you're still stuck in a situation where you have to do something different to support every single video card and all you've done is add an unnecessary layer of abstraction to the process.
If video card makers can't work with the OSS community, what makes you think they're going to be able to cooperate with a standards body any better?
You can also have your ears nailed to your loudspeakers, which would be similarly useful.
I just got a GPS for my Handspring Visor, and it installed the software and libraries into the Visor from Rom somewhere. No CDs, floppies or anything.
I used to wonder if in the PCI, PCIX, USB, Cardbus protocols an allowance is made to download the driver from the 'unknown' device. The machine can always be updated with newer drivers, but the machine should never report 'unknown' much like cisco routers, which have a very basic IOS in its rom before the full ios is loaded. Flash is cheap especially the size that is required for a basic driver.
Next, I suppose the driver should be either in source format, or an intermediate machine language, or (my favorite) an XSLT type language which is compiled by the kernel. Drivers with hidden sources will be tricky here. This should also allow newer OSes to simply work on all the hardware.
But like the x86 processor, like windows, like cisco, like oracle, the current system is bad but maintains somebodys monopoly at a high cost to the consumer.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Thanks for the link to the Open Graphics Project, that was new to me. I run a website for ameatur operating system developers and while a 3d version of a VESA BIOS would be nice I can say that most of us would just be happy with open specs. Note to others: People are trying to make all kinds of truly open hardware, on of the biggest sites is http://www.opencores.org/
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
How about putting the driver on the board with a ROM chip , use hardware encryption or some other hardware DRM to protect it, which could be flashed to update it, etc. this happens on occasion for hardware devices.... then expose the driver through a standard API that anyone could implement, whether commercial or OSS... don't need to disclose how it works... just how to trigger it.
A fool throws a stone into a well and a thousand sages can not remove it.
Actually, I'd like it if hardware was *less* smart. Driver bugs are much easier to diagnose and fix than firmware bugs, and the fixes are easier to apply.
The real problem with video drivers is software patents. The graphics vendors have to be paranoiacally secretive about how their cards work, because they're all violating thousands of patents that should never have been granted in the first place. If you want to fix this situation, call your congresscritter.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
The logic that is being used is the same logic that spawned the winmodem. So that there is some silly peice of junk software that is coded by chimps that seems to have lockup problems on the OS that your using. In addition it makes the diagnostics of the device a total pain in the rear.
Leaving functionality up to "driver guys" really makes me cringe, its just really bad form. The hardware should be so simple to interface with that most people could just forgo the driver, leaving the drivers in the hands of the high performance nerds.
I completely understand that this would result in slightly more expensive graphics cards in the short term. I get that every 5-10 years the "basic" functionality needs to be bumped to something better. I even get that it seems like a pretty good way to have flexibility by not locking your hardware into a mold. There are some real issues that would need to be addressed, but I think the increased cost of hardware is really worth it.
I dont expect that the video card industry would even bother to move in a direction which may be less profitable, even if it did mean that systems would be more reliable. But I still feel the need to rant about solutions that save a nickle by causing a dollars worth of headache to the customer.
Storm
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...
I'd much rather have the card vendors get together and agree on a system of standards that could wrap up X, Quartz, GDI, OpenGL and DirectX into some standardized video description language. Do for video what PostScript did for print.
This would probably entail a performance penalty at first, but if the engineering resources that are currently being dedicated to creating drivers for each and every little card were re-applied, it could come out ahead in short order.
The only thing keeping this from happening is getting Microsoft, ATI, nVidia, and the community to agree on such a standard.
The US free market: two halves of a government-granted duopoly are free to set the market price.
Didn't microchannel do this very thing?
--- Do you believe in the day?
The motto of anything in life should be Keep It Simple, Stupid.
1. Hardware-based drivers simply adds another layer of interface, another place for something to go wrong. The software side has to eventually interface with the hardware, and adding another layer of drivers does nothing to facilitate this process.
2. STOP BEING SO DAMNED PROPRIETARY. Sure, trade secrets and everything. I understand that much. But how much sense would it make to keep HOW to interact with the card secret? It's like saying, "I wrote this great song on the piano, and since you only need 24 keys to play it instead of all 88, I'll only give you the 24 keys." Sure, most of the time, when you're playing the piano, you don't need ALL 88 keys, but it sure is nice to have them if you need them.
So simple, it's almost stupid.
Isn't that what Microsoft's been trying to do with the DX10 spec? Last I checked, things that 'fail DX10' don't get rated for it, so it can essentially start providing a DX10-compliant card that answers the basic questions. I think the biggest issue that MS has is with backwards compatability...People get cranky when they see a shiny new OS and are told that 'Your computer can't handle it'. Citius
Site slashdotted out? Use SharePapyrus under Site Directory
"Commercial Advantage"
Actually, it's perceived commercial advantage of the horrible American video card makers (ATI and NVidia) that is the problem. They seem to think that by being as different as they can to the competition then hiding behind NDAs and funky specs that they will have some advantage. In reality there's no real advantage if the hardware is performing properly. Problem is the drivers contain hack after kludge to work around quirks in the hardware.
The big guys don't want you seeing how shitty their hardware really is because they can hide the shittyness in a binary only driver that makes it do the right thing.
I drink to make other people interesting!
The Poster is correct, think of all the time and energy wasted, not to mention monopolies locked in, just because people cut corners. When modem manufactures stopped putting firmware and controllers onboard modems we had a great resource hogging fiasco on our hands. If graphics card vendors would put the open gl routines right on the card, we wouldn't need to skirt around the GPL to get drivers that were "legal". IF wireless cards put the firmware on the cards, then they wouldn't have to "hide" the code to maintaing FCC compliance.
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.
Generally all you need is a simple 2D graphics API to get the card up and running (which is what VESA does). The main issue has been getting a popular cross platform (ie, PPC, MIPS, other) API working which hasn't been tied to the BIOS and will work with say, Open Firmware or EFI. I'd imagine with the uptake of EFI you'll see more pushes towards making this work. SciTech Software has been working on things like this for a while now. On the other front, drivers other common devices such as peripherals would do well to be abstracted from the OS to a degree so other OS'es (besides fan favourites) can benefit from the work developers do on implementing drivers.
I DISAGREE!
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
DVI is a dumb protocol. It sends an uncompressed image with every refresh.
Neither VNC nor X11 is like that.
X11 is good enough to play 3D games over gigabit. You just send the OpenGL. Video works fine too -- you don't send it raw, and certainly not at your monitor's refresh rate.
Let's look at these in turn. First, OpenGL. OpenGL is a nice, popular 3D graphics format. Software generates the OpenGL instructions, which get turned into identical but probably different OpenGL instructions (on a 1:1 basis) in some OS library, which then gets translated into identical but almost certainly different OpenGL instructions (still on a 1:1 basis) by the graphics driver, which hands the data to the card. If the communications is not wrappered, then the OpenGL instructions sent over the bus will need to be converted into yet another different but identical set of OpenGL instructions that the GPU can actually process. There is absolutely no way on Earth that this can be an efficient mechanism. A single standard representation would be infinitely superior.
Renderman/NURBS. This is the format used by tools such as BMRT, Pixar's Renderman software, Rhino 3D, etc. We're talking ultra high-end 3D graphics with shaders to die for. In terms of CPU and I/O requirements, it's not cheap to get this stuff done at any decent level of performance. The CPU part isn't that important, as the GPU won't be able to do any better. What you will do, however, is eliminate the I/O of rendered data over a slow bus. Sending a shader or an image over would be painless, and graphics is I/O-bound, not CPU-bound.
Loadable Microcode and Firmware. These are NOT the same thing, as I've already said. But what they do allow you to do is more effectively divide the driver between what is on the CPU and what is on the GPU. You can run anything in firmware, provided the GPU has the instruction set for it. It also pr
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And if something goes wrong, the graphics card is broken, because the ROM is gone, and has to be flashed by some pros for a hefty amount of $$$. What a GREAT idea!
This sig does not contain any SCO code.
Yes indeed Theovon, that's a commercial fact of life, and it's not going to change. Since it's not going to change, kernel designers who want to protect Linux from the problems inherent in closed binary drivers should have structured the driver architecture in a manner that addresses this, but they haven't.
Driver manufacturers who "need" closed code (because it saves their company money) should be forced to run it in their own private and heavily MMU-isolated VM, with absolutely no exceptions allowed to this rule.
nVidia and ATI will complain that this reduces their performance somewhat --- tough, that's the price you pay for insisting on using your own opaque driver code and refusing to provide full hardware interface documentation.
Companies who DO provide full specs so that we can write open drivers to them would benefit from increased performance, which is a nice incentive to be more open.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Or it could just come with a backup ROM, too.
1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
There is no single API that could be created to handle every scenario that someone may come across. What if you don't like DirectX or OpenGL? You'd be SOL if there was no other choice.
ATI and nVidia have such radically different approaches to how their hardware interacts with a computer that any compromise would be unrealistic. And what's wrong with software drivers? Even if the drivers were located on the board in Flash Ram, that won't mean there will be no more bugs to deal with. And it's a hell of a lot easier dealing with software bugs than hardware.
Plus, updating the drivers on the board carries a very large risk of destroying the hardware. Anyone who has killed a mobo by losing power during an update knows what I mean.
"Sounds" like a great idea, but upon further thought turns out to be bad. I can just imagine graphics chip company XYZ deciding to stick in a ROM chip that contains a "driver" which automatically locks out certain "features". What's worse, with the current trend of rootkits, and forcefully installing spyware on user's machines, I would not be surprise dif such a built-in driver (stored on a ROM chip) would phone home automatically and periodically.
Yes, there is "driver hell". But at least u can get non-official drivers that may be optimized and/or may unlock certain features turned off by default.
In short, putting the drivers on the video card is kind of like going back in time and allowing intel to go full fledged forward with their "ID"ing chips!
like for example the firmware upload for several wireless cards, this part of the cards driver software could also be uploaded after booting before initialising the card
...
this wouldnt raise any price in hardware design or manufacturing while doing simply what the article states already
on the other hand, no graphic card manufacturer himself would be freely switching to such a "generic" solution, as he couldn't build in any shit he thinks about for advertising his card as uberdoom, quake, unreal whatever fps excess it is capable off instead of making it usable for all users
i cant see why current drivers cant be shipped on a small amount of flash memory built onto the card. flash memory is *cheap*, drivers are relatively small - 32MB would likely be plenty to house drivers for a variety of OS's. the flash mem could use a standard OS driver eg. mass storage device. this goes for all but the cheapest devices... rather than educating every pc user to understand the process of 1) identify device 2) locate manufacturers website 3) download appropriate driver for device/OS 4) install, the whole pro ess could be alot simpler. yes the drivers would eventually become out of date but so are the drivers that are distributed on CD, its still better than nothing, and because its just flash memory, the drivers could be updated on the device automatically if you ever install a newer downloaded driver. yes its not *quite* as cheap, but how much neater would it be if each device in your puter could identify itself and suggest a driver rather than throwing its hands in the air and explaining to you that the computer has detected another 'unknown device'. over.
Though I've always hoped HW would include its own drivers, I always worry about a virus being 'flashed' in there.
Er, I think you're confused as to who's in a position of power here. If Linux devs go out of their way to make life difficult for Nvidia and ATI, they'll just give Linux the finger and stop producing drivers for it altogether.
From the point of view of the management of these companies, providing Linux drivers is a thing they do on the side to get good PR with open-source devs and on the off chance the OS becomes a significant market in the future. But force them to do extra work or put them at risk of exposing their proprietary tricks to competitors by opening their drivers, and bam they're outta here.
How about putting the driver on the board with a ROM chip , use hardware encryption or some other hardware DRM to protect it, which could be flashed to update it, etc.
This is exactly what the original poster was explaining... now you are asking for an extra/larger flash chip on the board, possibly with encryption hardware, etc. Even if this only adds $1-2, multiply that by a couple million cards and that's a significant margin.
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.
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.
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
...and not a software engineer.
...except that it already has been a reality. This isn't a novel idea. It's happened at least three times in the past, and it will happen again in the future. Somebody comes up with a standard driver API, people implement it, cards work everywhere... Then some smartass graphics chip maker wants a competetive edge and either intentionally breaks the API, or comes up with a feature that doesn't fit the standard, and suddenly you can't use the on board driver anymore if you want the full featureset. Then the whole standard goes out the window, there's chaos for a few years (decades) and the whole process starts over again.
The abstraction you describe could just as easily be software in flash on the card as software in RAM on a PC. Your chip design wouldn't have to change at all for this to be a reality...
The Open Graphics Project has opinions about that.
Those opinions and a dollar seventy nine will get you a coffee at starbucks. The day your solution to the driver problem works is the last day you will ever be employed as a chip designer ever again. It's also the day that pigs will fly and the day there is ice skating in hell.
Agreed - hardware is expensive. However, developer time for software driver development is also expensive. I don't know if, in the long run, an onboard chip would be more or less expensive than OS driver headaches. I suppose, unfortunately, the current product offerings indicate that it's not worth the onboard hardware.
I've been watching the Open Graphics project with interest - I hope they succeed. Such a card is exactly what I would want - I don't care about being able to play games at a zillion FPS, but I do want to be able to rotate geometric plots in 3D smoothly and have an accelerated desktop.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Hmm, $17 if you mail out the fritzed chip. $30 if you have a new one mailed to you.
Or you could splurge & spend the $58 and buy the programmer yourself.
That ethernet cards can't use a generic driver right out of the box. Can anyone give me a good reason that a NIC couldn't use a generic driver to get say a slower connection, but one that will allow you to download the new drivers?
http://www.openfirmware.org/
The basic premise is that the interface (eg. video card) contains a chip holding system-independet drivers.
It's been running on most commercial Unix systems with proprietary hardware for years.
I can say little about VNC, ICA, or NX. The other two though...
You couldn't be more wrong about your ranking of X11 and RDP.
X11 is pretty decent, especially if you use the modern extensions.
(the Xfixes, Damage, and font-related stuff)
RDP is a joke. The sickest thing is that we tunnel it over
TCP/IP. RDP already includes those layers of the network
stack. To anyone with a clue about the behavior of network
protocol congestion control and similar issues, this is an
obviously bad thing to do. RDP has all sorts of crazy-shit
features designed by a committee. Microsoft then tacked on
some interesting extras to bring the "quality" below even
that of the blecherous CIFS protocol.