On Fri, Aug 19, 2016 at 09:56:04AM -0700, Jason Ekstrand wrote:
> This has been the only caller since we deleted the meta fast clear code.
> ---
> src/mesa/drivers/dri/i965/blorp_clear.c | 127
> +++++++++++++++++++++++++++++-
Patches 19-27 are:
Reviewed-by: Topi Pohjolainen <topi.pohjolai...@intel.com>
> src/mesa/drivers/dri/i965/brw_meta_util.c | 122 ----------------------------
> src/mesa/drivers/dri/i965/brw_meta_util.h | 6 --
> 3 files changed, 124 insertions(+), 131 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/blorp_clear.c
> b/src/mesa/drivers/dri/i965/blorp_clear.c
> index c91aed9..fd27bf7 100644
> --- a/src/mesa/drivers/dri/i965/blorp_clear.c
> +++ b/src/mesa/drivers/dri/i965/blorp_clear.c
> @@ -24,7 +24,6 @@
> #include "util/ralloc.h"
>
> #include "blorp_priv.h"
> -#include "brw_meta_util.h"
> #include "brw_defines.h"
>
> #include "nir_builder.h"
> @@ -77,6 +76,128 @@ brw_blorp_params_get_clear_kernel(struct blorp_context
> *blorp,
> ralloc_free(mem_ctx);
> }
>
> +/* The x0, y0, x1, and y1 parameters must already be populated with the
> render
> + * area of the framebuffer to be cleared.
> + */
> +static void
> +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;
> +}
> +
> void
> blorp_fast_clear(struct blorp_context *blorp, void *batch,
> const struct brw_blorp_surf *surf,
> @@ -94,8 +215,8 @@ blorp_fast_clear(struct blorp_context *blorp, void *batch,
> memset(¶ms.wm_inputs, 0xff, 4*sizeof(float));
> params.fast_clear_op = BLORP_FAST_CLEAR_OP_CLEAR;
>
> - brw_get_fast_clear_rect(blorp->isl_dev, surf->aux_surf,
> - ¶ms.x0, ¶ms.y0, ¶ms.x1, ¶ms.y1);
> + get_fast_clear_rect(blorp->isl_dev, surf->aux_surf,
> + ¶ms.x0, ¶ms.y0, ¶ms.x1, ¶ms.y1);
>
> brw_blorp_params_get_clear_kernel(blorp, ¶ms, true);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> index 52b7be4..499b6ea 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;
> -}
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> index d517237..b9c4eac 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> @@ -42,12 +42,6 @@ brw_meta_mirror_clip_and_scissor(const struct gl_context
> *ctx,
> GLfloat *dstX1, GLfloat *dstY1,
> bool *mirror_x, bool *mirror_y);
>
> -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);
> -
> bool
> brw_meta_set_fast_clear_color(struct brw_context *brw,
> struct intel_mipmap_tree *mt,
> --
> 2.5.0.400.gff86faf
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
