Mesa (master): i965/gen6+: Add code to perform blits on the render path (" blorp").

[Paul Berry]

Module: Mesa
Branch: master
Commit: 506d70be21cd3469118de89297cba0c0f709c1ae
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=506d70be21cd3469118de89297cba0c0f709c1ae

Author: Paul Berry <stereotype441 at gmail.com>
Date:   Sun Apr 29 22:44:25 2012 -0700

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/i965/Makefile.sources   |    1 +
 src/mesa/drivers/dri/i965/brw_blorp.cpp      |   32 +-
 src/mesa/drivers/dri/i965/brw_blorp.h        |  136 ++++-
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |  863 ++++++++++++++++++++++++++
 src/mesa/drivers/dri/i965/brw_context.h      |    8 +
 src/mesa/drivers/dri/i965/gen6_blorp.cpp     |  397 +++++++++++-
 src/mesa/drivers/dri/i965/gen7_blorp.cpp     |  311 +++++++++-
 src/mesa/drivers/dri/intel/intel_fbo.c       |    9 +
 8 files changed, 1730 insertions(+), 27 deletions(-)

Diff:   http://cgit.freedesktop.org/mesa/mesa/diff/?id=506d70be21cd3469118de89297cba0c0f709c1ae