On 05/10/2012 11:21 AM, Paul Berry wrote:
> 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(-)
> create mode 100644 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
I tried to review this, and discovered that I'm not qualified to review blit
code.
----
Chad Versace
chad.vers...@linux.intel.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
