diff options
author | Paul Berry <stereotype441@gmail.com> | 2012-08-29 14:26:48 -0700 |
---|---|---|
committer | Paul Berry <stereotype441@gmail.com> | 2012-09-12 14:44:13 -0700 |
commit | 5fd67fac14d7f35c311eb5c671be8d4ae9b2ea37 (patch) | |
tree | 1036ffa153637d9dac735258f4f119e12e9ba123 /src/mesa | |
parent | 1a75063d5f829547b75b60ae64bddf3905b4cb8f (diff) |
i965/blorp: Reduce alignment restrictions for stencil blits.
Previously, we aligned all stencil blit operations to multiples of the
size of a tile, since stencil buffers use W-tiling, and blorp has to
approximate this by configuring the 3D pipeline for Y-tiling and
swizzling coordinates.
However, this was unnecessarily conservative; it turns out that the
differences between W-tiling and Y-tiling are confined to 32-byte
sub-tiles within the 4k tiling pattern; the layout of these 32-byte
sub-tiles within the larger 4k tile is the same (8 sub-tiles across by
16 sub-tiles down, in column-major order). Therefore we only need to
align stencil blit operations to multiples of the sub-tile size.
Note: although the performance improvement of this change is probably
quite small, the fact that W-tiling and Y-tiling formats only differ
within 32-byte sub-tiles will be essential in a future patch to ensure
that stencil blits work correctly between parts of the miptree other
than level/layer 0. Making this change provides handy documentation
(and validation) of this fact.
NOTE: This is a candidate for stable release branches.
Acked-by: Eric Anholt <eric@anholt.net>
Diffstat (limited to 'src/mesa')
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 23 |
1 files changed, 17 insertions, 6 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp index 67274dcc40a..6bf37b8d4aa 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp @@ -1779,16 +1779,27 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct brw_context *brw, if (dst.map_stencil_as_y_tiled) { /* We must modify the rectangle we send through the rendering pipeline * (and the size of the destination surface), to account for the fact - * that we are mapping it as Y-tiled when it is in fact W-tiled. Y - * tiles have dimensions 128x32 whereas W tiles have dimensions 64x64. - * We must also align it to a multiple of the tile size, because the - * differences between W and Y tiling formats will mean that pixels are - * scrambled within the tile. + * that we are mapping it as Y-tiled when it is in fact W-tiled. + * + * Both Y tiling and W tiling can be understood as organizations of + * 32-byte sub-tiles; within each 32-byte sub-tile, the layout of pixels + * is different, but the layout of the 32-byte sub-tiles within the 4k + * tile is the same (8 sub-tiles across by 16 sub-tiles down, in + * column-major order). In Y tiling, the sub-tiles are 16 bytes wide + * and 2 rows high; in W tiling, they are 8 bytes wide and 4 rows high. + * + * Therefore, to account for the layout differences within the 32-byte + * sub-tiles, we must expand the rectangle so the X coordinates of its + * edges are multiples of 8 (the W sub-tile width), and its Y + * coordinates of its edges are multiples of 4 (the W sub-tile height). + * Then we need to scale the X and Y coordinates of the rectangle to + * account for the differences in aspect ratio between the Y and W + * sub-tiles. * * TODO: what if this makes the coordinates (or the texture size) too * large? */ - const unsigned x_align = 64, y_align = 64; + const unsigned x_align = 8, y_align = 4; x0 = ROUND_DOWN_TO(x0, x_align) * 2; y0 = ROUND_DOWN_TO(y0, y_align) / 2; x1 = ALIGN(x1, x_align) * 2; |