On Monday 21 March 2005 12:50, Peter Zubaj wrote: > >I just realized something - isn't the application supposed to change > Z test for that ? > > I don't know, but all application I tested and which uses alpha test - > has z test enabled and all displays errors (tuxracer, enemy territory, > fire - from mesa/demos) > > >Maybe what really happens is that disabling Z test is broken. > > Z test is not disabled - it is enabled. Problem is - even alpha test > fails (and fragment is discarded) z value is still written (and this > looks wrong).
Bingo. If setting 0x4F14 to 1 does indeed enable early Z testing, this is easily explained: For every fragment, the card *first* does the Z test. The Z test passes, so the new depth is written out. The fragment program is probably run after the Z test, but this detail doesn't matter. What matters is that the alpha test discards the fragment, but only after Z has already been written. If, on the other hand, 0x4F14 is set to 0, Z testing happens *after* the alpha test and everything's fine. > >On the other hand, as Nicolai points out it would be nice to know > what that register does and whether other bits have any function. > > AFAIK: > > fglrx initialize 0x4f14 register to 0x00000001, but when alpha test is > enabled it sets it to 0x00000000. I have to do more tests to see if > fglrx sets this register back to 0x00000001 (for now looks, like it is > not set back, but I need to make test program for it). Yes, that would need further testing. If fglrx does not set the register back to 1, that would indicate that there's more to this bit than just early Z. Possible explanations could be (a) a relation to other Z acceleration tricks, (b) fglrx is just being stupid or (c) switching between early and late Z testing is very slow or broken in hardware. But if fglrx *does* reset the register to 1 when alpha test is disabled, we can pretty much say with certainty that it enables early Z testing. cu, Nicolai
pgp21RdGhCMMO.pgp
Description: PGP signature
