> 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. However, I'd like to get back on the subject of the original FBO blitters: it looks like that the plan is to use the same shader for depth or color and get the job done via masking depth or color channels; I think that this is not optimal since then to blit color and depth requires 2 draw calls with different state vectors. Those differences in state vector will likely do amusing things in a driver, typically a stall between calls and quite likely a different shader bits to driver because of the masking. For the use case of most or all the screen blit this is ok, but for lots of small blits this is likely bad. So, it would be much better to use a distinct shader for each of the 3 possibilities to drop the draw call and state change count. -Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
