Too much attention was paid to the first paragraphs, and not enough to
the last little note that "oh, by the way, the rendered things
themselves still have to be clipped to just 8192 wide/high".

Fixes GTF's clip.c test with 4096 or higher width on ivb, where one of
the triangles got the upper half of its pixels dropped.
---
 src/mesa/drivers/dri/i965/gen6_viewport_state.c |   15 +++++++++++----
 src/mesa/drivers/dri/i965/gen7_viewport_state.c |   15 ++++++++++-----
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_viewport_state.c 
b/src/mesa/drivers/dri/i965/gen6_viewport_state.c
index 95243f0..cffb16c 100644
--- a/src/mesa/drivers/dri/i965/gen6_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_viewport_state.c
@@ -43,11 +43,18 @@ gen6_upload_clip_vp(struct brw_context *brw)
    vp = brw_state_batch(brw, AUB_TRACE_CLIP_VP_STATE,
                        sizeof(*vp), 32, &brw->clip.vp_offset);
 
-   /* According to the Sandybridge PRM, Volume 2, Part 1, Section 6.3.8
-    * "Vertex X,Y Clamping and Quantization", the screen-aligned 2D
-    * bounding-box of an object must not exceed 16K pixels in either X or Y.
+   /* According to the "Vertex X,Y Clamping and Quantization" section of the
+    * Strips and Fans documentation, objects must not have a screen-space
+    * extents of over 8192 pixels, or they may be mis-rasterized.  The maximum
+    * screen space coordinates of a small object may larger, but we have no
+    * way to enforce the object size other than through clipping.
+    *
+    * If you're surprised that we set clip to -gbx to +gbx and it seems like
+    * we'll end up with 16384 wide, note that for a 8192-wide render target,
+    * we'll end up with a normal (-1, 1) clip volume that just covers the
+    * drawable.
     */
-   const float maximum_post_clamp_delta = 16384;
+   const float maximum_post_clamp_delta = 8192;
    float gbx = maximum_post_clamp_delta / (float) ctx->Viewport.Width;
    float gby = maximum_post_clamp_delta / (float) ctx->Viewport.Height;
 
diff --git a/src/mesa/drivers/dri/i965/gen7_viewport_state.c 
b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
index 7036ef6..150e890 100644
--- a/src/mesa/drivers/dri/i965/gen7_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
@@ -44,12 +44,17 @@ gen7_upload_sf_clip_viewport(struct brw_context *brw)
    brw->clip.vp_offset = brw->sf.vp_offset;
 
    /* According to the "Vertex X,Y Clamping and Quantization" section of the
-    * Strips and Fans documentation, Ivybridge and later don't have a maximum
-    * post-clamp delta.  However, the guardband extent must fit in [-32K, 32K)
-    * which gives us a maximum size of 64K.  Use 65000 rather than 65536 to be
-    * somewhat cautious---make the guardband slightly smaller than the maximum.
+    * Strips and Fans documentation, objects must not have a screen-space
+    * extents of over 8192 pixels, or they may be mis-rasterized.  The maximum
+    * screen space coordinates of a small object may larger, but we have no
+    * way to enforce the object size other than through clipping.
+    *
+    * If you're surprised that we set clip to -gbx to +gbx and it seems like
+    * we'll end up with 16384 wide, note that for a 8192-wide render target,
+    * we'll end up with a normal (-1, 1) clip volume that just covers the
+    * drawable.
     */
-   const float maximum_guardband_extent = 65000;
+   const float maximum_guardband_extent = 8192;
    float gbx = maximum_guardband_extent / (float) ctx->Viewport.Width;
    float gby = maximum_guardband_extent / (float) ctx->Viewport.Height;
 
-- 
1.7.10.4

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to