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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
