On Tue, Feb 4, 2014 at 10:29 AM, Rogovin, Kevin <kevin.rogo...@intel.com> wrote: > > >> I don't believe our hardware can support GL_ARB_shader_stencil_export. >> The render target write message can take RGBA, depth, and sample masks, >> but not stencil. Without that, it's not at all obvious how to implement it. > > There is a terrible hack-ish way to do it, but I stress the word terrible and > hackish and > it may not work correctly depending on the tile modes and all that fun. > > Here goes. Assuming the depth-stencil is D24S8 we can do this and that the > tile modes work out: > > Bind src depth-stencil as RGBA_8UI, the depth should be in RGB and the > stencil in A. > Bind the dst depth-stencil as RGBA_8UI as well. Fragment shader is simple > unfiltered > read and write to dest. If not writing to depth or stencil, mask our RGB or A > respectively. > > The above does not handle MSAA->non-MSAA. Going further, it can be done in > general > on *paper* with GL_ARB_texture_view if that is extended to allow D24S8 to be > on the same > castable category as RGBA_8UI. The main catch is how the tile modes work out, > i.e. if the > tile mode for a D24S8 is "compatible" with a RGBA_8UI render target.
This is how r300g does it. It blits D24S8 as RGBA_UNORM. Gallium has texture views and it has no limitations on how you can change the format, so it's pretty trivial. r300g changes the format, then calls our "meta" code (u_blitter). Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
