[Mesa-dev] Texture from RenderBuffer for blitting

Rogovin, Kevin kevin.rogovin at intel.com
Mon Feb 10 02:06:56 PST 2014


Hi,

  I was looking over the _mesa_meta_BlitFramebuffer and in particular, blitframebuffer_texture(). A few idea (feedback welcome and wanted):

Firstly, the check if src is a renderbuffer or not. I think it might be a good idea to add an internal Mesa API to allow a driver to specify that a renderbuffer can be used as a texture. I believe that atleast for i965, this would make that blitframebuffer_texture() would likely always be used when i965 blitframebuffer implementation uses _mesa_meta_BlitFramebuffer.

Secondly, if a driver supports MRT, I think it would be better to use an MRT fragment shader instead of a looping over each render target. Indeed, by doing so, the read associated to the texture fetch would happen once instead of once per color buffer.

Thirdly (and this is quite minor), rather than using a VBO to hold the vertex data, I'd think it would be better if the vertex data was static values { {0,1}, {1,0}, {1,1}, {0,1} } and the vertex shader would have uniforms that takes the local normalized values and produces the texture coordinate (and clip positional values). The reason being that since the same buffer object is used, changing it and then using it means that if an application does several blits in a row then an underlying driver will either stall or do "something" for the buffer object (for i965 since it is small, this means copy it usually).

Lastly, in handling the case where the src and dest are the same buffers in the case where the buffer can be viewed as a texture rather than using CopyTex[Sub]Image to a temporary buffer, to instead use blitframebuffer_texture() onto a temporary texture and then use blitframebuffer_texture() onto the dest. The main benefit being that various format conversion cases are then handled properly (since CopyTex[Sub]Image requires the formats to match more closely than BlitFramebuffer requires).




-Kevin



More information about the mesa-dev mailing list