aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_meta_util.c
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2016-08-19 03:53:33 -0700
committerJason Ekstrand <[email protected]>2016-08-29 12:17:34 -0700
commit007d8a6d04a807f5c65c8545398ee5639f2eee31 (patch)
tree23924bb7d5ba777fddd8270c5d6fc58e3a5e9cec /src/mesa/drivers/dri/i965/brw_meta_util.c
parentc8ff36228d6f5d48f700437e4a5520d8b6de13ab (diff)
i965: Move get_fast_clear_rect to blorp_clear.c
This has been the only caller since we deleted the meta fast clear code. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri/i965/brw_meta_util.c')
-rw-r--r--src/mesa/drivers/dri/i965/brw_meta_util.c122
1 files changed, 0 insertions, 122 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c b/src/mesa/drivers/dri/i965/brw_meta_util.c
index 52b7be4b693..499b6eacc0c 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -441,125 +441,3 @@ brw_meta_set_fast_clear_color(struct brw_context *brw,
return updated;
}
-
-/* The x0, y0, x1, and y1 parameters must already be populated with the render
- * area of the framebuffer to be cleared.
- */
-void
-brw_get_fast_clear_rect(const struct isl_device *dev,
- const struct isl_surf *aux_surf,
- unsigned *x0, unsigned *y0,
- unsigned *x1, unsigned *y1)
-{
- unsigned int x_align, y_align;
- unsigned int x_scaledown, y_scaledown;
-
- /* Only single sampled surfaces need to (and actually can) be resolved. */
- if (aux_surf->usage == ISL_SURF_USAGE_CCS_BIT) {
- /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
- * Target(s)", beneath the "Fast Color Clear" bullet (p327):
- *
- * Clear pass must have a clear rectangle that must follow
- * alignment rules in terms of pixels and lines as shown in the
- * table below. Further, the clear-rectangle height and width
- * must be multiple of the following dimensions. If the height
- * and width of the render target being cleared do not meet these
- * requirements, an MCS buffer can be created such that it
- * follows the requirement and covers the RT.
- *
- * The alignment size in the table that follows is related to the
- * alignment size that is baked into the CCS surface format but with X
- * alignment multiplied by 16 and Y alignment multiplied by 32.
- */
- x_align = isl_format_get_layout(aux_surf->format)->bw;
- y_align = isl_format_get_layout(aux_surf->format)->bh;
-
- x_align *= 16;
-
- /* SKL+ line alignment requirement for Y-tiled are half those of the prior
- * generations.
- */
- if (dev->info->gen >= 9)
- y_align *= 16;
- else
- y_align *= 32;
-
- /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
- * Target(s)", beneath the "Fast Color Clear" bullet (p327):
- *
- * In order to optimize the performance MCS buffer (when bound to
- * 1X RT) clear similarly to MCS buffer clear for MSRT case,
- * clear rect is required to be scaled by the following factors
- * in the horizontal and vertical directions:
- *
- * The X and Y scale down factors in the table that follows are each
- * equal to half the alignment value computed above.
- */
- x_scaledown = x_align / 2;
- y_scaledown = y_align / 2;
-
- /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
- * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
- * Clear of Non-MultiSampled Render Target Restrictions":
- *
- * Clear rectangle must be aligned to two times the number of
- * pixels in the table shown below due to 16x16 hashing across the
- * slice.
- */
- x_align *= 2;
- y_align *= 2;
- } else {
- assert(aux_surf->usage == ISL_SURF_USAGE_MCS_BIT);
-
- /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
- * Target(s)", beneath the "MSAA Compression" bullet (p326):
- *
- * Clear pass for this case requires that scaled down primitive
- * is sent down with upper left co-ordinate to coincide with
- * actual rectangle being cleared. For MSAA, clear rectangle’s
- * height and width need to as show in the following table in
- * terms of (width,height) of the RT.
- *
- * MSAA Width of Clear Rect Height of Clear Rect
- * 2X Ceil(1/8*width) Ceil(1/2*height)
- * 4X Ceil(1/8*width) Ceil(1/2*height)
- * 8X Ceil(1/2*width) Ceil(1/2*height)
- * 16X width Ceil(1/2*height)
- *
- * The text "with upper left co-ordinate to coincide with actual
- * rectangle being cleared" is a little confusing--it seems to imply
- * that to clear a rectangle from (x,y) to (x+w,y+h), one needs to
- * feed the pipeline using the rectangle (x,y) to
- * (x+Ceil(w/N),y+Ceil(h/2)), where N is either 2 or 8 depending on
- * the number of samples. Experiments indicate that this is not
- * quite correct; actually, what the hardware appears to do is to
- * align whatever rectangle is sent down the pipeline to the nearest
- * multiple of 2x2 blocks, and then scale it up by a factor of N
- * horizontally and 2 vertically. So the resulting alignment is 4
- * vertically and either 4 or 16 horizontally, and the scaledown
- * factor is 2 vertically and either 2 or 8 horizontally.
- */
- switch (aux_surf->format) {
- case ISL_FORMAT_MCS_2X:
- case ISL_FORMAT_MCS_4X:
- x_scaledown = 8;
- break;
- case ISL_FORMAT_MCS_8X:
- x_scaledown = 2;
- break;
- case ISL_FORMAT_MCS_16X:
- x_scaledown = 1;
- break;
- default:
- unreachable("Unexpected MCS format for fast clear");
- }
- y_scaledown = 2;
- x_align = x_scaledown * 2;
- y_align = y_scaledown * 2;
- }
-
- *x0 = ROUND_DOWN_TO(*x0, x_align) / x_scaledown;
- *y0 = ROUND_DOWN_TO(*y0, y_align) / y_scaledown;
- *x1 = ALIGN(*x1, x_align) / x_scaledown;
- *y1 = ALIGN(*y1, y_align) / y_scaledown;
-}