On 07/11/2011 04:03 PM, Chad Versace wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/11/2011 12:49 PM, Dan McCabe wrote:
On 07/09/2011 08:56 AM, Chad Versace wrote:
Up until this point, we incorrectly believed that the stencil buffer is
Y-tiled. In fact, it is W tiled. From PRM Vol 1 Part 2 Section 4.5.2.1
W-Major Tile Format:
"W-Major Tile Format is used for separate stencil."
Since the stencil buffer is allocated with I915_TILING_Y, the span
functions must decode W tiling through a Y tiled fence.
On gen5 with intel_screen.hw_must_use_separate_stencil enabled,
Fixes-Piglit-test: stencil-drawpixels
Fixes-Piglit-test: stencil-scissor-clear
Fixes-Piglit-test: readpixels-24_8
Note: This is a candidate for the 7.11 branch
Signed-off-by: Chad Versace<[email protected]>
---
src/mesa/drivers/dri/intel/intel_span.c | 52
+++++++++++++++++++++----------
1 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_span.c
b/src/mesa/drivers/dri/intel/intel_span.c
index 153803f..f39c008 100644
--- a/src/mesa/drivers/dri/intel/intel_span.c
+++ b/src/mesa/drivers/dri/intel/intel_span.c
@@ -141,28 +141,46 @@ intel_set_span_functions(struct intel_context *intel,
/**
* \brief Get pointer offset into stencil buffer.
*
- * The stencil buffer interleaves two rows into one. Yay for crazy hardware.
- * The table below demonstrates how the pointer arithmetic behaves for a buffer
- * with positive stride (s=stride).
- *
- * x | y | byte offset
- * --------------------------
- * 0 | 0 | 0
- * 0 | 1 | 1
- * 1 | 0 | 2
- * 1 | 1 | 3
- * ... | ... | ...
- * 0 | 2 | s
- * 0 | 3 | s + 1
- * 1 | 2 | s + 2
- * 1 | 3 | s + 3
- *
+ * The stencil buffer is W-tiled, yet the drm buffer is allocated with
+ * I915_TILING_Y. So here we must decode the W tiling through a Y fence.
*
+ * From PRM Vol 1 Part 2 Section 4.5.2.1 W-Major Tile Format:
+ * "W-Major Tile Format is used for separate stencil."
*/
static inline intptr_t
intel_offset_S8(int stride, GLint x, GLint y)
{
- return 2 * ((y / 2) * stride + x) + y % 2;
+ /* f: (x, y) -> (fx, fy) */
+ int fx = x / 8;
+ int fy = y / 4;
+
+ /* e: (x, y) -> (ex, 0) */
+ int ex = (x % 8) / 4;
+
+ /* d: (x, y) -> (dx, dy) */
+ int dx = (x % 4) / 2;
+ int dy = (y % 4) / 2;
+
+ /* c: (x, y) -> (cx, cy) */
+ int cx = x % 2;
+ int cy = y % 2;
+
+ int s = stride;
+ intptr_t o = 0;
+
+ if (s> 0) {
+ /*f*/ o += 16 * fx + 4 * s * fy;
+ /*e*/ o += 2 * s * ex;
+ /*d*/ o += 4 * dx + 8 * dy;
+ /*c*/ o += cx + 2 * cy;
+ } else {
+ /*f*/ o += 16 * fx + 4 * s * fy;
+ /*e*/ o += 2 * s * (1 - ex);
+ /*d*/ o += 4 * dx + 8 * (1 - dy);
+ /*c*/ o += cx + 2 * (1 - cy);
+ }
+
+ return o;
}
#define WRITE_STENCIL(x, y, src) buf[intel_offset_S8(stride, x, y)] = src;
Can stride ever be negative? If so, why?
Yes. The stride is negative for window-system renderbuffers.
If the app ever specified a negative stride, it could have fixed at buffer
creation time (by also adjusting the buffer base address). No need to worry
about that issue thereafter.
No-can-do. As far as I know, X demands that its buffers have negative stride.
On the other hand, negative strides could be considered evil :).
Yes, they are :)
Also, can x or y ever be negative?
No.
[snip]
Using "*", "/" and "%" for bit manipulations of pixel addresses should be
avoided. Shifts and masks are clearer for bit manipulation, IMO.
Regarding the offset computation, it might be useful to think of x,y addresses
of the tile and then of x,y addresses within the tile to make the code more
readable and perhaps simplify your computations.
Damn crazy hardware. Here we need to decode a W tile through a Y fence, so the "x,y
addresses of the tile and then of x,y addresses within the tile" are non-existent.
The fence mapping has carved up the W tile and made a mess of it. So, there are no tile
addresses to compute.
Here is the little meaning that my equations possess:
- (fx + ex, fy) is the address of a 4x4 block in which (x, y) resides.
- Decompose that 4x4 block into 2x2 blocks. (dx, dy) is
the address of that 2x2 block within the 4x4 block.
- (cx, cy) is the address of (x, y) within that 2x2 block.
For example, if stride is a power of 2, tile size is 2x2 pixels, and your x and
y address bits look like (upper case bits are tile bits and lower case letters
are intra-tile bits):
XXXXXx
and
YYYYYy
then the offset for that pixel and a power of two stride has a bit pattern that
looks like
YYYYXXXXyx
But the devil is in the details and this might not be valid for our particular
(crazy?) hardware. YMMV.
Can a similiar set of bit operations replicate intel_offset_S8()?
Yeah. I started working out the details, but stopped after concluding it
wasn't my problem :) But I can make it my problem and give you a hand
with that formulation.
I'll do that tomorrow.
cheers, danm
- --
Chad Versace
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOG4EuAAoJEAIvNt057x8iZowQAIJXGQBGlBDUC9US7U+r83Jp
SulXEua8kE/KHfptTN7WoPgmdmrRKH2JMcIC2kcCUE6I9/PdSRV2VIaVgWr/pMdP
Z1SUVM4lQP57rPRe5iZmlS43u4gUSQaEr0fbYU6RynD4tXphH5W8gnF5QdF6/pGo
LNIaGJ4ya3euAWX+aJwYI7Z+skbZ1ucyDUbII+RpDOnrO80v4E8uVrrGizr5PQtp
VrX6Zpr1s800kgUXBtkiREK71VSSUYSxFEQ3xP/xBYzUcyhJxpqapN7qOWu9tOI+
2OGy9MX2JuMwqmjVDLg8ap6dsQ92OjKtsgatNJ94Llg5xfP1hN7t91IRWtYpK9/V
v90d/OEu4R1z+8864oqmo7oKlAKersFhhrvIUQ22N6lVxzQqjoR+Ph9BXUwhgnKb
iJ3JMDE90UrJWeO+EnqBbL75HgvgcjZr15PlqZSKNvcNd5M5R/7lPKg/3Zbk88cy
NRJtnrQdWrFk7aGrdi2bfIqm1teCq9kWBBbYuKQn1buXsXtMEC46SJKS9vSua/pF
nVvr1361M9c+Whd4jTSErd/vLvgUA0dxptWPAestalT6i7yYoeq+ZxA236TIqvDZ
1AbSiDeXzslv3ArshbWrtQAZw33cop1z9HGiYMNCdbsdLVJtN1zf0Y25VV3nBcom
3anb5cgbYF601N7wI+CN
=Y7Df
-----END PGP SIGNATURE-----
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
