summaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorPaul Berry <[email protected]>2012-08-29 14:26:48 -0700
committerPaul Berry <[email protected]>2012-09-12 14:44:13 -0700
commit5fd67fac14d7f35c311eb5c671be8d4ae9b2ea37 (patch)
tree1036ffa153637d9dac735258f4f119e12e9ba123 /src
parent1a75063d5f829547b75b60ae64bddf3905b4cb8f (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 <[email protected]>
Diffstat (limited to 'src')
-rw-r--r--src/mesa/drivers/dri/i965/brw_blorp_blit.cpp23
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;