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

[Ian Romanick]

On 02/04/2014 01:29 AM, Rogovin, Kevin 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.

More recent Intel GPUs only do separate stencil.  Stencil is stored in a
tile mode that the texture hardware doesn't understand.  You can modify
the texture coordinates to get the locations you want, and this is a big
part of what blorp does.

> 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.

If the application does a depth-only blit, we have to disable color
writes (or not attach the color surface) in meta anyway.  Similarly for
color-only blits.  If we don't write color in the shader, the hardware
still tries to write to the color buffer... it just tries to write garbage.

> -Kevin
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>