[Mesa-dev] [PATCH 26/35] meta: Use common GLSL code for blits

[Rogovin, Kevin]

> 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