glxtest with fglrx / r200

[Roland Scheidegger]

For anyone interested, I have attached a modified pretty_print_command_stream.tcl. It should make it easier to analyze the fglrx driver on r200 cards, since it knows all register names (which are documented) of the r200. (This version is certainly useless on r300 based cards.) I have also inserted some register names from the original radeon, if they looked like they have the same purpose than on r200 based cards (those names which have prefix R200 are from the r200_reg.h, those with RADEON are from radeon_reg.h or from radeon_drv.h).

Some interesting (imho) things I found:
The fglrx driver uses the old txformat/txfilter etc. registers from the radeon for tex units 0-2, since it never run on the old radeon cards this is a bit weird.
It writes to some undocumented registers:
- 0x1c30, right between RB3D_ZSTENCILCNTL and RB3D_ZMASKOFFSET. Seems to write always 0 though.
- 0x2cf8. No idea what this is good for, but in the couple of demos I tried the driver always wrote 0x17.
- 0x2680. Always 0.
- 0x2210, 0x2214, 0x2218, 0x221c. Those actually exist in radeon_reg.h, but I have some doubts they have the same use (they are the emmissive part of the material property, but other parts of the same material use registers which are for something different on r200).
- 0x2284. This one is interesting. The script gives this the name "X_VAP_PVS_WAITIDLE", the driver always emits this right before R200_SE_VAP_CNTL. Apparently it exists on r200 too. Looks like it forces the VAP (whatever that stands for...) to wait. Would we need to emit that too?
- 0x3254 (ZCACHE_CTLSTAT, I only saw the value 0x05), 0x325c (only saw 0x03), 3260 (only saw 0x0).

Roland

r200_pretty_print_command_stream.tcl
Description: Tcl script