iris: viewport state, sort of

diff --git a/src/gallium/drivers/iris/iris_state.c b/src/gallium/drivers/iris/iris_state.c
index cfd08267ac51b8dfc90fedff2f9d53cb70b9d586..f94e788d25c112791bd35aca1261badac789d6c7 100644 (file)
--- a/src/gallium/drivers/iris/iris_state.c
+++ b/src/gallium/drivers/iris/iris_state.c
@@ -684,12 +684,132 @@ iris_set_stencil_ref(struct pipe_context *ctx,
    ice->state.dirty |= IRIS_DIRTY_WM_DEPTH_STENCIL;
 }
 
+
+struct iris_viewport_state {
+   uint32_t sf_cl_vp[GENX(3DSTATE_SF_length)];
+};
+
+static float
+extent_from_matrix(const struct pipe_viewport_state *state, int axis)
+{
+   return fabsf(state->scale[axis]) * state->translate[axis];
+}
+
+#if 0
+static void
+calculate_guardband_size(uint32_t fb_width, uint32_t fb_height,
+                         float m00, float m11, float m30, float m31,
+                         float *xmin, float *xmax,
+                         float *ymin, float *ymax)
+{
+   /* According to the "Vertex X,Y Clamping and Quantization" section of the
+    * Strips and Fans documentation:
+    *
+    * "The vertex X and Y screen-space coordinates are also /clamped/ to the
+    *  fixed-point "guardband" range supported by the rasterization hardware"
+    *
+    * and
+    *
+    * "In almost all circumstances, if an object’s vertices are actually
+    *  modified by this clamping (i.e., had X or Y coordinates outside of
+    *  the guardband extent the rendered object will not match the intended
+    *  result.  Therefore software should take steps to ensure that this does
+    *  not happen - e.g., by clipping objects such that they do not exceed
+    *  these limits after the Drawing Rectangle is applied."
+    *
+    * I believe the fundamental restriction is that the rasterizer (in
+    * the SF/WM stages) have a limit on the number of pixels that can be
+    * rasterized.  We need to ensure any coordinates beyond the rasterizer
+    * limit are handled by the clipper.  So effectively that limit becomes
+    * the clipper's guardband size.
+    *
+    * It goes on to say:
+    *
+    * "In addition, in order to be correctly rendered, objects must have a
+    *  screenspace bounding box not exceeding 8K in the X or Y direction.
+    *  This additional restriction must also be comprehended by software,
+    *  i.e., enforced by use of clipping."
+    *
+    * This makes no sense.  Gen7+ hardware supports 16K render targets,
+    * and you definitely need to be able to draw polygons that fill the
+    * surface.  Our assumption is that the rasterizer was limited to 8K
+    * on Sandybridge, which only supports 8K surfaces, and it was actually
+    * increased to 16K on Ivybridge and later.
+    *
+    * So, limit the guardband to 16K on Gen7+ and 8K on Sandybridge.
+    */
+   const float gb_size = GEN_GEN >= 7 ? 16384.0f : 8192.0f;
+
+   if (m00 != 0 && m11 != 0) {
+      /* First, we compute the screen-space render area */
+      const float ss_ra_xmin = MIN3(        0, m30 + m00, m30 - m00);
+      const float ss_ra_xmax = MAX3( fb_width, m30 + m00, m30 - m00);
+      const float ss_ra_ymin = MIN3(        0, m31 + m11, m31 - m11);
+      const float ss_ra_ymax = MAX3(fb_height, m31 + m11, m31 - m11);
+
+      /* We want the guardband to be centered on that */
+      const float ss_gb_xmin = (ss_ra_xmin + ss_ra_xmax) / 2 - gb_size;
+      const float ss_gb_xmax = (ss_ra_xmin + ss_ra_xmax) / 2 + gb_size;
+      const float ss_gb_ymin = (ss_ra_ymin + ss_ra_ymax) / 2 - gb_size;
+      const float ss_gb_ymax = (ss_ra_ymin + ss_ra_ymax) / 2 + gb_size;
+
+      /* Now we need it in native device coordinates */
+      const float ndc_gb_xmin = (ss_gb_xmin - m30) / m00;
+      const float ndc_gb_xmax = (ss_gb_xmax - m30) / m00;
+      const float ndc_gb_ymin = (ss_gb_ymin - m31) / m11;
+      const float ndc_gb_ymax = (ss_gb_ymax - m31) / m11;
+
+      /* Thanks to Y-flipping and ORIGIN_UPPER_LEFT, the Y coordinates may be
+       * flipped upside-down.  X should be fine though.
+       */
+      assert(ndc_gb_xmin <= ndc_gb_xmax);
+      *xmin = ndc_gb_xmin;
+      *xmax = ndc_gb_xmax;
+      *ymin = MIN2(ndc_gb_ymin, ndc_gb_ymax);
+      *ymax = MAX2(ndc_gb_ymin, ndc_gb_ymax);
+   } else {
+      /* The viewport scales to 0, so nothing will be rendered. */
+      *xmin = 0.0f;
+      *xmax = 0.0f;
+      *ymin = 0.0f;
+      *ymax = 0.0f;
+   }
+}
+#endif
+
 static void
 iris_set_viewport_states(struct pipe_context *ctx,
                          unsigned start_slot,
                          unsigned num_viewports,
                          const struct pipe_viewport_state *state)
 {
+   struct iris_viewport_state *cso =
+      malloc(sizeof(struct iris_viewport_state));
+
+   for (unsigned i = start_slot; i < start_slot + num_viewports; i++) {
+      float x_extent = extent_from_matrix(&state[i], 0);
+      float y_extent = extent_from_matrix(&state[i], 1);
+
+      iris_pack_state(GENX(SF_CLIP_VIEWPORT), cso->sf_cl_vp, vp) {
+         vp.ViewportMatrixElementm00 = state[i].scale[0];
+         vp.ViewportMatrixElementm11 = state[i].scale[1];
+         vp.ViewportMatrixElementm22 = state[i].scale[2];
+         vp.ViewportMatrixElementm30 = state[i].translate[0];
+         vp.ViewportMatrixElementm31 = state[i].translate[1];
+         vp.ViewportMatrixElementm32 = state[i].translate[2];
+         /* XXX: in i965 this is computed based on the drawbuffer size,
+          * but we don't have that here...
+          */
+         vp.XMinClipGuardband = -1.0;
+         vp.XMaxClipGuardband = 1.0;
+         vp.YMinClipGuardband = -1.0;
+         vp.YMaxClipGuardband = 1.0;
+         vp.XMinViewPort = -x_extent;
+         vp.XMaxViewPort =  x_extent;
+         vp.YMinViewPort = -y_extent;
+         vp.YMaxViewPort =  y_extent;
+      }
+   }
 }
 
 static void