[Mesa-dev] [PATCH 27/31] i965: Move get_fast_clear_rect to blorp_clear.c

Pohjolainen, Topi topi.pohjolainen at gmail.com
Thu Aug 25 07:32:02 UTC 2016


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.pohjolainen at 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(&params.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,
> -                           &params.x0, &params.y0, &params.x1, &params.y1);
> +   get_fast_clear_rect(blorp->isl_dev, surf->aux_surf,
> +                       &params.x0, &params.y0, &params.x1, &params.y1);
>  
>     brw_blorp_params_get_clear_kernel(blorp, &params, 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list