On Thu, Sep 30, 2010 at 1:43 PM, José Fonseca <jfons...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
