[Mesa-dev] first attempt at shader stencil export

[Alex Deucher]

On Thu, Sep 30, 2010 at 1:43 PM, José Fonseca <jfonseca at vmware.com> wrote:
> On Thu, 2010-09-30 at 10:19 -0700, Roland Scheidegger wrote:
>> On 30.09.2010 16:44, 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,
>> > although it could be certainly possible, by reading the texture as i32.
>>
>> No this won't work as you can't read a z24s8 format a i32 (not the same
>> typeless group, number of components needs to be the same as well as all
>> components need to have same number of bits).
>> But the format list suggests this is possible. For z24s8 you could
>> presumably use DXGI_FORMAT_R24G8_TYPELESS. For depthstencil view it
>> should be possible to then use DXGI_FORMAT_D24_UNORM_S8_UINT. For
>> reading depth use DXGI_FORMAT_R24_UNORM_X8_TYPELESS - for reading
>> stencil similarly use DXGI_FORMAT_X24_TYPELESS_G8_UINT. That's at least
>> my interpretation. Note you can't read both components at once (there is
>> no DXGI_FORMAT_R24_UNORM_G8_UINT format), you need different resource
>> views for that (presumably because the components don't have the same
>> type, so this is disallowed). Despite that reading depth will return
>> first (red) component, stencil second (green).
>
> Interesting.
>
> Gallium should have similar restraints: I recall Dave Airlie saying that
> AMD's recent ships have separate storage for depth and stencil, and
> DirectX10 rules accommodate that quite well.
>

Correct.  evergreen asics require separate allocations for depth and stencil.

Alex

> This means that Z24_S8 should be disallowed in sampler views: either it
> is Z24_X8 or X24_S8. And only one component is returned.
>
> It also means we need to add X24_S8 formats to gallium.
>
> Jose
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>