Keith Whitwell wrote: > Jerome Glisse wrote: >> On 2/26/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>> Jerome Glisse wrote: >>> > On 2/26/07, Roland Scheidegger <[EMAIL PROTECTED]> wrote: >>> >> Christoph Brill wrote: >>> >>> Attached is a mini-patch to add the address of early Z to r300_reg.h >>> >>> and use it. Jerome Glisse helped me with this patch. Thanks. :-) >>> >> Not really related directly to the patch itself, but it seems to >>> me that >>> >> the conditions when to enable early-z are a bit wrong. First, I'd >>> think >>> >> you need to disable early-z when writing to the depth output (or use >>> >> texkill) in fragment programs. Second, why disable early-z >>> specifically >>> >> if the depth function is gl_never? Is that some workaround because >>> >> stencil updates don't work otherwise (in that case should certainly >>> >> rather check for that) or something similar? >>> >> >>> >> Roland >>> > >>> > Yes we need to disable early z when the fragment program write to >>> > z buffer, so far there isn't real support for depth writing in the >>> driver >>> > (it's in the todo list). I fail to see why we should disable early >>> z when >>> > there is texkill instruction (and stencil disabled), if we disable >>> early >>> > z then if the fragment doesn't pass the test in the early pass it >>> > won't after texkill so will be killed anyway (and better kill early >>> then >>> > at the end). >>> >>> If you don't disable early z, you can end up writing values to the depth >>> buffer for fragments that are later killed. >>> >>> Keith >> >> Doesn't early z only discard fragment that fail z test and doesn't write >> z value, differing the write after fragment operation ? > > I guess it depends on the hardware - at least some do both the test and > write early. You'd have to test somehow. > > If it does do the writeback early, you need to also look at disabling > when alphatest is enabled. Indeed the driver already does that, r300 chips apparently do early z write (http://ati.amd.com/developer/gpups/index.html mentions "Force Alpha Test Enable" "Can identify problems related to early Z test"). As for stencil, I'm actually not sure that stencil isn't performed (that was just a guess for that disabling of early z when gl_never z test is used, since in that case you're probably updating stencil, what's the point of doing rendering at all otherwise) - since it's a shared stencil/depth buffer it would make sense for the hardware to perform stencil test at the same time and thus it would still work with early z. IIRC I think there was some talk about some differences there between r300 and r400, can't remember though. Test apps should easily reveal if it works.
Roland ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
