In the way, way back times there was a spunky startup called 3dfx which made the 'Voodoo' video card. It was fast and it had enough fill rate that doing mip-mapped textures really flew. There was another company called nVidia that made the a new graphics engine based on NURBs. 3Dfx published a straight forward API called 'Glide' which was pretty close to the metal and nVidia partnered with Sega to publish an API to this new engine.

It was a great time to program graphics, I had both cards and really liked the Glide API (even wrote a toy 3D graphics engine on top of it). But one of the things that I didn't like was that if you got a game it would have the 'Voodoo' version (as was the case with the Tomb Raider 1 and 2) or the 'Sega' version. They would look great with the right hardware and they would look like crap without it (falling back to software rendering).

So Microsoft created an API to rule them all and said do your best with this API, and while games were not as impressive as they might be with a direct/dedicated API, they were at least workable on several different configs (and the PC has a bazillion number of configurations). Once the graphics hardware crossed the minimum acceptable visual threshold somewhere in the Nvidia TNT2 / PowerVR / Voodoo2 era with the crappy, but functional, DirectX 3, the convenience of not having to patch was trumping best fidelity for most of the market. All of the private APIs stopped being worked on at that point.

There was the OpenGL/DirectX debate, but even Carmack suggests that without an active SGI pushing it forward that DirectX has eclipsed OpenGL it in terms of capability.

So now that DirectX is so dominant, we come to AMD's issue. AMD (actually the old ATI now a part of AMD) has some really killer graphics architect types. They can imagine really really cool ways of connecting CPUs to GPUs to memory which would allow stunning realism with less work on the part of the programmer (which is code for 'even lame programmers would look good.') Except that programmers won't program to a graphic card feature if it isn't in Direct X because then they have a fork in their code base or it sucks on vendor Y which doesn't do X etc.

So for a graphics architecture type at ATI(AMD) to get his or her cool feature in production, they have to design it, build it, convince Microsoft to add it to DirectX, possibly give up rights to some of the IP so that others can implement something like it, and then wait for everyone to catch up so that when Direct X version n+1 ships you can use it on your card which is now 2 years old.

Kinda sucks doesn't it?

If ATI(AMD) offered their own API that they wrote then they could update their API at the same rate they rolled out new silicon features and be much more agile. Hence our friend Huddy in the referenced article trying to make the argument that you (the game developer) would be better off if you weren't "held back" by Direct X.

I've talked with folks like Huddy in the past and have suggested that one strategy for making this happen would be to go 'open' with the API. Which is to say publish the source code that could be compiled on open source systems so that non-Windows OS's could support high performance 3D acceleration (all features) without having to run a Windows driver or the Windows OS, on the hope that in doing so we might be able to create a 'better' gaming/graphics experience outside of Microsoft's control, which in turn would put pressure on Microsoft should that loss of control be perceived as threatening their core business.

The challenge for that strategy is the whole "we are stuck in the X11 model stone age" that most of these OS's are mired in. (I am so tempted to resurrect SunTools, it probably sucks more than I remember but it was really fast even on a Sun3 so it should be like prescient on a modern machine)

So you've got the graphics card vendors looking for more flexibility, that is a good thing. We should try to leverage that to get better (usable) open source drivers out them.