glxtest with fglrx / r200

2004-10-28 Thread 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


Re: glxtest with fglrx / r200

2004-10-28 Thread Nicolai Haehnle
On Thursday 28 October 2004 20:11, Roland Scheidegger wrote:
 - 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?

The guessed register name is from me. On the R300, fglrx almost always 
writes 0 to this register before changing any vertex processor-related 
state, so I assume that it has some kind of serialising purpose. However, I 
have yet to run into any situation where emitting it makes any difference 
in my own code, so I don't know this for sure.

cu,
Nicolai


pgp0GdyzVtEM4.pgp
Description: PGP signature