[Mesa-dev] first attempt at shader stencil export

[Roland Scheidegger]

On 04.10.2010 16:43, Roland Scheidegger wrote:
> On 03.10.2010 13:14, Dave Airlie wrote:
>>>> 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.
>>>
>>> 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.
>> Okay I've updated the branch,
>>
>> http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-stencil-export
>>
>> though I need to go back and rebase it so its in-order changes and cleaner.
>>
>> I've added the two X24S8/S8X24 formats to gallium, moved to
>> TGSI_SEMANTIC_STENCIL
>> and fixed the early Z check in softpipe.
>>
>> The state tracker now uses sampler views into the same texture to get
>> the values.
>>
>> I need to check it works on r600 when I get back to the hw, and add a
>> check in the st for the new formats being supported.
> 
> I think this is definitely taking the right direction. I only briefly
> skimmed through it, but this struck me:
> +PIPE_FORMAT_X24S8_USCALED , plain, 1, 1, x24, u8 , , , _x__, zs
> +PIPE_FORMAT_S8X24_USCALED , plain, 1, 1, u8 , x24 , , , _y__, zs
> 
> I think X24S8 should have swizzle _y__, and S8X24 _x__.

Oh, forgot to mention, presumably we'd also need
X32_S8X24_USCALED and Z32_X8X24_FLOAT if I got the names consistent...
I don't think any driver implements this (there could be support missing
elsewhere too) but certainly dx10 hardware should be able to support
these formats. Though it looks like Evergreen won't have the unused
24bits for that, so that might not work without some more code.

Roland