R6xx/R7xx 3D programming guide released

It will be interesting to see in what manner they will release information for the next hardware generations, when they presumably will have completed the necessary infrastructure and policy changes to make it less of an engineering and especially legal burden to write and release proper documentation.

That is one of the major points behind having Gallium and having AMD/Intel/etc helping with the releases.

With the old Linux driver model you had to create at least 2, probably 3, different sets of drivers to run Linux. You needed the Linux DRM stuff, the Xorg DDX stuff, then a driver based off of Mesa's OpenGL stack, the 'dri' driver. With the Xorg DDX you had about 50% of the code of the driver developed just to deal with modesetting. With Mesa/DRI drivers the card-specific code was a large percentage of of the actual OpenGL implimentation... so each driver had, effectively, have it's own branch.

With the Gallium3D stuff the majority of hardware-specific code is isolated and stuck in the winsys (or whatever) part of the module.

Each state-tracker, which provides the application level API, then runs on top of a layer above the low-level hardware-specific code. So once a Gallium state tracker is created it's much much easier to make it run well on new hardware.

This reflects the modern design of GPUs. Mesa hardware specific stuff was originally designed for fixed-function cards which had their own unique OpenGL stuff.. but all modern hardware (since ATI R300 and onward) are based on programmable shader pipelines and are much more general purpose. The modern drivers are much like having everything software rendered, more or less, and treat the GPU as a co-processor for the CPU.

This way we can run the same OpenGL code, same EXA acceleration code, same OpenCL, OpenVR, etc on each new bit of hardware.

Once all the relatively modern drivers are ported to using Gallium then the Mesa OpenGL stuff should be able to be cleaned up quite a bit and optimization can be done easier.

----------------------------

This is like the difference between modern Wireless code in the Linux kernel vs what we had 2-3 years ago.

With the original Wireless cards on the market the onboard firmware took care of most of the 802.11 stuff... so that the Kernel developers treated wireless cards as simply a regular ethernet device that happenned to use air instead of twisted wire... rather as a software-controlled radio network device.

So as the hardware matured and got cheaper the drivers took on more and more of the functionality, but Linux didn't adapt. So what ended up happenning is that each driver had it's own 802.11 implimentation.

This caused all sorts of headaches... depending on the drivers different hardware had vastly different capabilties. So applications like wpa_supplicant and kismet had application-level drivers for each popular device in order to properly support them. Since each driver had to rewrite it's own 80211 implimentation then the amount of development effort that went into supporting a single wireless card was massive.

With the mac80211 stack it's generic enough that now the amount of hardware-specific code is much much less. Drivers are developed much quicker, have much more capabilities quicker, and user space is much much more consistant.

We have advanced tools now like 'iw' and a lot of the features that were once only avialable in Madwifi are now avialable for almost all mac80211-based drivers across the board.

Gallium is sorta like that. Isolate as much as the hardware specific code to a small as a module as possible.