I have a different question. If NVidia provide updated proprietary linux drivers free of charge in a timely manner, why is it important from a purely practical sense whether or not they provide open source ones? - Joany 02-02-08Many of the quick shot answers that are used to position Open-Licensed software simply do not matter to the vast majority of computer users. As I explained to a friend, literally just a few days ago when talking about Vista, when I started using Linux it wasn't because I cared about user freedoms. It wasn't because I was against Microsoft. It wasn't because I cared about being able to access the source code or modify programs as I saw fit. It wasn't for the lack of a price tag on most distributions. I started using Linux because I was bored in the back of a Burger King.
The theological and emotional factors of Open-Licensed software that drive many of the concerns today are simply lost on the average computer user who has been with Microsoft Windows for as long as they can remember. There need to be tangible benefits to having Open-Licensed drivers that go beyond the limited scope of the Free Software Foundation.
3DFX
The first example that I brought up to the defend Open-Licensed drivers back when Joany asked the question concerned 3DFX. 3DFX used to be the dominant graphics powerhouse for personal computers, and was largely undone by massive corporate arrogance and mis-steps, such as declaring that gamers only wanted 16bit color, or that raw frame-rate mattered more than visual effects. For many elder High-End computers the Voodoo Graphics cards are almost the standard. These computers are fully functional with nothing wrong to be found, other than almost non-existent device driver support for the Voodoo Graphics cards. Projects to map OpenGL calls to the MiniGL or Glide API systems are largely dead, and the only display choice for many a Voodoo Owner today is a basic Vesa display mode.
What would have happened though if 3DFX had opened up the register specification and the tools to make the drivers for the Voodoo Graphics cards? It would be possible for driver developers today to build effective 3D drivers for Voodoo Graphics cards. Projects like Compiz-Fusion and the 3D interfaces on KDE4 could easily fit into the limited Glide API, and the Voodoo Card design would be perfect for those wanting to have a low-power, low-impact, 3D desktop. Given the cost of creating a Voodoo Chipset today, mini-computers like the Asus EEEPC could offer limited 3D support for only five or six dollars.
The first point then to having Open-Licensed drivers is hardware security. Even if a vendor is put in a position where they have to file for bankruptcy, or find themselves on a buyout with intention to terminate the product line, customers won't be locked out of the hardware.
Radeon 8500
The second example given in response covered the ATi R200 family of graphics processors, better known as the Radeon 8500 series. The Radeon 8500 was one of ATi's longest lived products lines with multiple integrated and discrete cards. Even after the launch of the Radeon 9700 series, the Radeon 8500 architecture lived on in the lower set of the 9x00 series, specifically the Radeon 9000, Radeon 9100, and Radeon 9200 families. In fact, even when Radeon x1x00 cards were entering the market, the Radeon 8500 remix's were still selling on the low end.
In 2006 AMD/ATi dropped support for these cards from their official Linux driver. The primary reason was that the Radeon 8500 family was a Pixel Shader 1.4 graphics card. The Radeon 9500 series onwards were all Pixel Shader 2.0 graphics cards. In order to clean-up the Fglrx driver and unify support, the older Radeon cards had to be dropped. A variety of other factors impacted the choice, such as what driver developers should focus their time and effort on.
The result is that the finalized 8.28 Fglrx release will eventually find a point where it is completely incompatible with changes made to the X.org X11 implementation, as well as changes made to the Linux Kernel Itself. Years before the cut-off date ATi had released programming documentation on the Radeon 8500, enabling X.org to create a working 3D driver. Recent versions of the X.org ATi driver have seen performance come within 90% of the original Fglrx drivers performance output. The X.org driver offers some features the Fglrx driver did not provide, such as TV input on All-in-Wonder cards.
As the source code to the X.org ATi driver is freely available, that driver can be compiled against any new kernel, and any new release of X.org. As long as Linux and X.org support the AGP and PCI hardware interfaces, 3D support will be available for Radeon 8500 class cards, even if no further changes to the driver are implemented.
The second point then is similar to the first. Older functional hardware that the vendor no longer can support either due to time or resources, can find communities willing to make sure that support continues.
Intel and Tile Base
One of the next points to be raised covered the Intel GPU's. From a performance standpoint the Intel GPU's are perhaps some of the worst graphics processing units ever made. In many cases the Intel GPU are merely graphics accelerators, and not graphics processing units.
Most of the Intel's GPU designs released under their Open-Licensed drops utilize a tile-based architecture : http://www.xbitlabs.com/articles/chipsets/display/i915g_2.html
While Tile-based rendering is rather rare for the PC market, the architecture was also used in many GPU's from PowerVR, such as the Kyro line-up and the Sega Dreamcast. Theoretically then, Intel's GPU documentation may shed light or help attempts to reverse engineer other GPU solutions that do not have proper driver support.
The third practical point for Open-Licensed drivers is that there can be tangible benefits can be had when trying to support similar products. This doesn't mean that the Intel documentation will lead to functional Kyro support, or the possibility of running a Compiz-Fusion desktop on a Deamcast, but writing a driver to support tile-based rendering for other platforms might be easier with examples already in hand.
RadeonHD Video
All of the points so far deal with older hardware, after a vendor has left the market, after a product has left the market, and when a current vendor could shed light on a previous vendor's product. What about right now? What are the benefits of an Open-Licensed driver today? One good example goes back to the Radeon 8500. The X.org driver for the Radeon 8500 offers support for TV input, a feature not in the Fgrlx driver.
Skip forward to the current
Support for Hardware accelerated video on the
AMD's John Bridgman had a correction to make on the support for Video Acceleration, noting that the separate hardware did carry through the R6xx series, prompting the strike-outs and clarifications.
Bridgman>One minor point though; the IDCT hardware actually carries Bridgman>Bridgman> through the entire R6xx line as well so I'm pretty sure we can open that up Bridgman> for 6xx parts as well. It's only the 7xx parts (including 780) where the separate Bridgman> IDCT hardware goes away. MC, which is the most time consuming part of video Bridgman> decode, is done on the 3d engine anyways; we just have special rounding modes for video vs 3d
I'm getting a crash course in accelerated video as Mr. Bridgman goes over this article. Oh well, when in doubt, ask the source, and so yet here's more clarification:
bridgman2> Saist; now your article is probably a bit *too* nice about us ;)The fourth practical point then is that feature support for video cards can be added where the original vendor might be affected by existing patents or licensed technology.
bridgman2> basically we expect to be able to open at least as much video decoding hardware
bridgman2> in 6xx as we did in the previous chips; the issue is that some of the 6xx chips
bridgman2> have additional video decoding hardware (UVD) which performs more of
bridgman2> the decoding task and that's the part we're not sure we can open up yet
**
bridgman2> Saist: roughly we should be able to accelerate maybe 60% or 70% of the video
bridgman2> processing workload; the big stink is because we may not be able to open up
bridgman2> the remaining portions
Video Optimization
A fifth point was brought up on the Freenode channels for Radeon Driver development. One of the channel visitors complained that the hardware cycle for graphics cards was moving too quickly. Vendors were unable to optimize their drivers for new graphics cards, which results in over all lower performance. There is a glaring problem that with the rapid growth of the GPU market, the standard 18month product development time is not leaving much room to optimize existing drivers to make the best use possible of various graphics cards. That is the hardware market though. If new products are not being put on the retail shelf by one company, a competitor will simply run off ahead with a better product. Radeon 9700 and Geforce 6600 GT come to mind as examples of when such events occurred.
Open-Licensed drivers offer a tangible benefit then to hardware and software vendors. This was the point I started to talk about on Blender.
but the possibility is available for existing Open-licensed software to be optimized for RadeonHD and X.org ATi drivers. Imagine what would happen if Blender was optimized to use GPU powered rendering through the Open-Licensed drivers? What would that mean for the movie industry which is always looking to slice costs? What would that mean for the gaming industry which is also looking to slice development costs?Linux, as an Operating System, has come to dominate in the entertainment production market, examples being the popular Dreamworks 3D animated movies made entirely on Linux powered boxes, as well as the BBC using Linux heavily behind the scenes to cut, edit, produce, and store their shows. The Halo movie planned by Microsoft was killed when Microsoft found out that the production team wasn't using Microsoft products for rendering, instead using Linux powered boxes.
The reasons for the domination are almost self-evident. On identical hardware a Linux Operating System is generally faster than a Microsoft Operating system per feature level. However, there is no scaling back on Operating Systems from Microsoft. With Linux, vendors are free to offer boxes that are stripped of non-essential programs and applications, and most of the heavy rendering systems in use today barely contain more than the linux kernel, the appropriate drivers for the hardware, the one or two programs the rendering box is designed for, and that's it.
So, what would happen if entertainment productions were able to take that current mixture another step forward? What if an entertainment production company hired a couple of hardware engineers whose only job was to optimize the RadeonHD driver specifically for a single program with a single graphics chipset?
What would happen if gaming companies started having their software engineers hang around the #radeonhd channels and actively committing patches to the driver? What would happen if the gaming industry had a say in how the drivers were optimized? What if they had the freedom to play around with their own optimizations?
That's the picture of where an open-licensed driver can lead to. Graphic production companies could shave off costs of upgrading to newer hardware as well as decreasing production time by optimizing the drivers. Being able to modify the drivers themselves, the OS kernel itself, the underlying kernel system, and the application code could result in noticeable performance increases. Gaming companies won't have to wait for a vendor to fix a graphics glitch or a bug in the driver, they can simply log into the source repository and submit their own patch.
The vendors themselves benefit as well. Under licenses like the GPLv2, any and all such changes have to be submitted back to the original vendor.
The very fifth reason open-licensed drivers matter, and a very current one, is that supporting an Open-Licensed driver can create jobs that weren't there, save money for companies, help optimize drivers outside of the original vendors aggressive product schedule, and allow customers and clients who rely on functional drivers to actually have a say in what goes on with the drivers.
1 comment:
What a wonderful post.
I have been trying to explain what you summarized in point five to several of my peers. Unfortunately, it appears that many of us have forgotten some of the most important lessons learned in school -- pay attention to history.
It wasn't that long ago that the 'dark ages' of video games were upon us. We had RPGs where the three dimensional worlds were scrobbled through one painful screen refresh at a time and blip blip blip were the trademarks of almost every graphical based engine.
Then it all changed.
A little game came along called Castle Wolfenstein. It was a huge step forward, but not quite as huge as its successor.
Doom pushed the limits of those old 386 and 486 chips at the time. A part of Doom's success relied upon using counter-mainstream techniques -- something entirely missing from our current culture. Part one was the 32 bit Watcom compiler to thunk into the wonderful world of 32 bit operation. The other was ModeX ( http://en.wikipedia.org/wiki/Mode_X ).
Stumbling. Hacking. Experimenting. Finally poof -- the video game era was changed almost instantly overnight.
Amen to the opening of graphics cards. May the mainstream game developers see the potential of churning out some custom card-specific tweaks to deliver the same jaw dropping changes that Wolfenstein and Doom brought us.
With the openness we stand a very real chance of changing the gaming world once again. I'd be pretty certain that this time it would deliver even more of an adrenaline rush than the first time someone twiddled their Cirrus Logic card register to pop into a 16 bit colour mode.
Post a Comment