On Sat, Oct 9, 2010 at 2:15 AM, Brian Paul <[email protected]> wrote: > On 10/07/2010 12:42 AM, Dave Airlie wrote: >> >> Okay I've pushed another iteration of the gallium + mesa + softpipe + >> r600g changes for accelerated stencil rendering to >> >> http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-stencil-export >> >> Quick patch summary by area: I've marked two mesa ones as needing some >> competent review. >> >> Gallium: >> add TGSI stencil semantic + capability >> add support for S8X24_USCALED, X24S8_USCALED, >> add sampler support for S8, >> and format support only for X32_S8X24_USCALED >> >> mesa: >> add FRAG_RESULT_STENCIL >> improve the texstore handlers for S8Z24 and Z24S8 (!!!!please review!!!!) > > One question here: why does the code try to preserve any existing > depth/stencil bits in the target texture buffer? For example, if we're > putting depth values into a Z+Stencil texture, why do the stencil bits > matter? Or another way: under what circumstance would we try to merge > separate depth/stencil images into one Z+Stencil texture?
The old code did this for GL_DEPTH_COMPENENT uploads, it kept the stencil values, so I decided to keep it consistent and if you upload GL_STENCIL_INDEX you get to keep the depth pieces, though I'm not really sure if that is every going to happen in reallife, but since I preferred just making the code generic it didn't seem like a major overhead. >> add a texstore handler for S8 (!!!!! please review !!!!!) > > The inner-most for-loop could be a memcpy(). good point, > > I'm OK with merging this. I'm sure we can fix any regressions that might > pop up. Cool I'll merge it early next week if nothing else pops up, just want to make my dumb piglit test a bit more useful. Dave. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
