This is not the end of reverse engineering for radeons

Vendors also use "reserved" for bitfields that may do X in stepping A of the chip, Y in
stepping B, and nothing at all in stepping C -- all while their own drivers actually do
something with that bitfield (perhaps surrounded by "if (stepping == A)" like statements).
Just because the original design intention was that programmers always use some other bitfield
for that particular purpose doesn't mean that some harried developer working from engineers
notes didn't happen to use a register that, while not intended for his desired purpose,
happened to work that way.  Reverse-engineering that driver would turn up the incorrect usage.

Oh, wait, all vendor drivers are bug-free, right?

(Not saying this is what happened -- I have no way of knowing -- but I have seen similar stuff
before, and even been there myself, telling customers using a certain API in effect to "do as
we say, not as we do".  Not for any malicious or secretive reason, just because we learned
stuff as we developed the code and some of the older code doesn't do it the best way.  Also
remembering from my machine-language programming days back on the 6502 where you could do some
cool stuff with undocumented op-codes -- until they came out with a slightly different version
of the chip that didn't do the same things with those undocumented ops.)