From 506d70be21cd3469118de89297cba0c0f709c1ae Mon Sep 17 00:00:00 2001 From: Paul Berry Date: Sun, 29 Apr 2012 22:44:25 -0700 Subject: i965/gen6+: Add code to perform blits on the render path ("blorp"). This patch expands the "blorp" component to be able to perform blits as well as HiZ resolves. The new blitting code is located in brw_blorp_blit.cpp. This includes the necessary fragment shader code to look up pixels in the source buffer (which is configured as a texture) and output them to the destination buffer (which is configured as the render target). Most of the time the fragment shader code is simple and straightforward, since it merely has to apply a coordinate offset, read from the texture, and write to the render target. However, in the case of blitting stencil buffers, things are more complicated, since the GPU stores stencil data using W tiling, and W tiling is not supported for textures or render targets. So, we set up the stencil buffers as Y tiled, and emit fragment shader code that adjusts the coordinates to account for the difference between W and Y tiling. Furthermore, since a rectangular region in W tiling does not necessarily correspond to a rectangular region in Y tiling, we widen the rectangle primitive to the nearest tile boundary and have the fragment shader "kill" any pixels that don't fall inside the actual desired destination rectangle. All of this is a necessary prerequisite for implementing MSAA, since we'll need to be able to blit between multisample color, depth, and stencil buffers and their non-multisampled counterparts, and none of the existing blitting mechanisms support multisampling. In addition, the new blitting code should speed up operations where we previously fell back to software rasterization, such as blitting of stencil buffers. The current fallback sequence is: first we try to do a blit using the hardware blitting engine. If that fails we try to do a blit using the render path. If that also fails then we do the blit using a meta-op (which may or may not fall back to software rasterization). Note that blitting using the render path has some limitations at the moment: it only supports a few formats, and it doesn't support clipping or scissoring. These limitations will be addressed in future patch series. v2: - Add the code that configures the WM program to gen{6,7}_emit_wm_config() and gen7_emit_ps_config() rather than creating separate ...enable() functions. - Call intel_prepare_render before determining which miptrees we are blitting from/to, because it may cause miptrees to be reallocated. - Allow the blit to mirror X and/or Y coordinates. - Disable blorp blits on Gen7 for now, since they aren't working yet. --- src/mesa/drivers/dri/intel/intel_fbo.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'src/mesa/drivers/dri/intel/intel_fbo.c') diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index 2f95ad06025..f92d78f378a 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.c +++ b/src/mesa/drivers/dri/intel/intel_fbo.c @@ -823,6 +823,15 @@ intel_blit_framebuffer(struct gl_context *ctx, if (mask == 0x0) return; +#ifndef I915 + mask = brw_blorp_framebuffer(intel_context(ctx), + srcX0, srcY0, srcX1, srcY1, + dstX0, dstY0, dstX1, dstY1, + mask, filter); + if (mask == 0x0) + return; +#endif + _mesa_meta_BlitFramebuffer(ctx, srcX0, srcY0, srcX1, srcY1, dstX0, dstY0, dstX1, dstY1, -- cgit v1.2.3