R600 Gallium3D Reorders Atom State Emission

The R600g patches for reworking the atom state emission ordering have landed, after having to infer the ordering sequence from the Catalyst binary blob command stream.

Back in July I wrote about errors in the Gallium3D driver with regard to the command stream with the Gallium3D driver command stream differing from the official Catalyst driver. This command stream ordering situation led to Gallium3D driver issues in handling HyperZ. The problem effectively came down to a likely R600+ GPU hardware bug. However, there's nothing cited as an errata within the public documentation and its unlikely any internal AMD Catalyst driver engineers would remember the details around the issue since the hardware in question is about five years old. Due to hardware errata, the only sure way to tell how to control the hardware is by looking at the closed-source driver's command stream to see how the binary blob is programming the hardware.

Jerome's patch for R600g was merged to Mesa Git master last week that reorders the Atom state emission to hopefully avoid GPU lock-ups. "To avoid GPU lockup registers must be emited in a specific order (no kidding ...). This patch rework atom emission so order in which atom are emited in respect to each other is always the same. We don't have any informations on what is the correct order so order will need to be infered from fglrx command stream."

/* !!!
* To avoid GPU lockup registers must be emited in a specific order
* (no kidding ...). The order below is important and have been
* partialy infered from analyzing fglrx command stream.
*
* Don't reorder atom without carefully checking the effect (GPU lockup
* or piglit regression).
* !!!
*/

This atom state emission reordering ended up just being over 100 lines of code changes after partially examining the fglrx driver's actual command stream ordering format.