[Mesa-dev] shader stencil export v(x+1)

Brian Paul brianp at vmware.com
Fri Oct 8 09:15:37 PDT 2010


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?


> add a texstore handler for S8 (!!!!! please review !!!!!)

The inner-most for-loop could be a memcpy().


> softpipe:
> add support for using shader stencil references
>
> mesa/st:
> add an option to allow a texture format to be picked we can't render to (for S8)
> use the shader stencil support to accel the drawpixels path
>
> r600g:
> add support for S8X24/X24S8, and S8
> add support for writing stencil shader.
>
> mesa: (need to write tests)(but I'd like to push without these if
> possible and get back to them later).
> add support for the GL extension to GLSL/mesa (!!!!! need GLSL review !!!!!)

I'm OK with merging this.  I'm sure we can fix any regressions that 
might pop up.

-Brian


More information about the mesa-dev mailing list