From 14ca30507f76ddd7d3d7119e69d7611d70699ffd Mon Sep 17 00:00:00 2001 From: Kenneth Graunke Date: Sat, 23 Dec 2017 14:33:04 -0800 Subject: [PATCH] iris: viewport state, sort of --- src/gallium/drivers/iris/iris_state.c | 120 ++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) diff --git a/src/gallium/drivers/iris/iris_state.c b/src/gallium/drivers/iris/iris_state.c index cfd08267ac5..f94e788d25c 100644 --- 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 -- 2.30.2