[Mesa-dev] first attempt at shader stencil export

[José Fonseca]

On Thu, 2010-09-30 at 07:44 -0700, José Fonseca wrote:
> On Thu, 2010-09-30 at 07:32 -0700, Brian Paul wrote:
> > On 09/30/2010 12:41 AM, Dave Airlie wrote:
> > > some background:
> > >
> > > so on r600g, the only way to directly write to the stencil is via the
> > > shader, using a transfer would require an extra step to flush the DS
> > > buffer out via the pipe again to make it useable by the hw as a DS
> > > buffer. So using the current gallium stencil draw would be a major
> > > overhead, compared to just doing it properly.
> > >
> > > So to do it properly I decided to expose the
> > > GL_ARB_shader_stencil_export type functionality.
> > >
> > > http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-stencil-export
> > >
> > > 7 commits in here:
> > >
> > > two simple one liners, add the cap to gallium headers, and add
> > > FRAG_RESULT_STENCIL to mesa.
> > > then a "fix" to the mesa texstore so it will store S8 in an 8/24 so we
> > > can put the stencil values in a texture.
> > > mesa state tracker support to use the new capability to hw accel
> > > drawpixels on the stencil (outputs to Y of FRAG_RESULT_STENCIL).
> > > r600g support for the capability take the second
> > > TGSI_SEMANTIC_POSITION output and use its Y value as stencil (looking
> > > at this now, I should probably be taking the X value really).
> > > very initial mesa/GLSL support for the extension (completely untested).
> > > initial softpipe support for the capability a demonstration.
> > >
> > > TODO:
> > > probably stop using Y (this was just because the hw uses Y), the GLSL
> > > extension just defines an integer output for the fragprog.
> > > fix the 24/8 texstore variant.
> > > write some test code for piglit and test the GL extension/GLSL bits.
> > >
> > > I'm a lot more interested in the non-GL extension bits as it allows
> > > stencil writes to work properly on r600g.
> > 
> > A few comments.
> > 
> > Instead of using semantic name=TGSI_SEMANTIC_POSITION, index=1 to 
> > indicate the stencil output, how about just defining a new 
> > TGSI_SEMANTIC_STENCIL label instead?  I think that'd be clearer.
> > 
> > I think the fragment stencil result is supposed to be an integer.  But 
> > in the softpipe changes, it looks like you're doing a [0,1]->[0,255] 
> > scaling at one point.
> > 
> > If we want to use this feature for implementing glDraw/CopyPixels 
> > functionality, the stencil values will be coming from a texture.  How 
> > do we sample that texture?  That is, which components of the texture 
> > image return the Z and/or stencil components?  Basically, we need to 
> > add a new row to the table in the tgsi.rst file for Z/Stencil 
> > textures.  Also, we need to clarify that fetching a stencil value 
> > returns an integer value, not a float normalized to [0,1].
> 
> DirectX 10 documentation concerning depth textures is quite peculiar,
> they suggest using typecasts:
> 
> http://msdn.microsoft.com/en-us/library/bb205074(v=VS.85).aspx#reading_the_depth-stencil_buffer_as_a_texture
> 
> But they specifically mention reading z24s8 stencil values this way,

... they *don't* specifically mention ...

> although it could be certainly possible, by reading the texture as i32. 
> 
> Jose
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev