[Mesa-dev] first attempt at shader stencil export
keithw at vmware.com
Thu Sep 30 02:45:32 PDT 2010
On Wed, 2010-09-29 at 23:41 -0700, 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.
> 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.
> 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.
This all looks great. I wasn't really aware of this extension, but it
looks like a good way to expose the functionality you need.
Can you make some updates to the gallium/docs directory to reflect the
additions you're making to the gallium interface?
More information about the mesa-dev