[Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.
Chad Versace
chad.versace at linux.intel.com
Wed Dec 4 15:07:06 PST 2013
On 12/04/2013 06:30 AM, Paul Berry wrote:
> Fast color clears of MSAA buffers work just like fast color clears
> with non-MSAA buffers, except that the alignment and scaledown
> requirements are different.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 +++++++++++++++++---------
> 1 file changed, 87 insertions(+), 44 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> index ab472e6..4d03cbe 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> @@ -239,8 +239,7 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct brw_context *brw,
> }
>
> /* If we can do this as a fast color clear, do so. */
> - if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
> - irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> + if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> !partial_clear && wm_prog_key.use_simd16_replicated_data &&
> is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
> memset(push_consts, 0xff, 4*sizeof(float));
> @@ -251,48 +250,92 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct brw_context *brw,
> */
> unsigned x_align, y_align, x_scaledown, y_scaledown;
>
> - /* 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 returned by intel_get_non_msrt_mcs_alignment(), but
> - * with X alignment multiplied by 16 and Y alignment multiplied by 32.
> - */
> - intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> - x_align *= 16;
> - 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;
> + if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
> + /* 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 returned by intel_get_non_msrt_mcs_alignment(), but
> + * with X alignment multiplied by 16 and Y alignment multiplied by 32.
> + */
> + intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> + x_align *= 16;
> + 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 {
> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> + * Target(s)", beneath the "MSAA Compression" bugget (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
> + * 4X Ceil(1/8*width) Ceil(1/2*height)
> + * 8X Ceil(1/2*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
> + * verticeally and either 4 or 16 horizontally, and the scaledown
> + * factor is 2 vestically and either 2 or 8 horizontally.
bugget, verticeally, and vestically! oh my!
Patches 1-6 are
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
But this patch 7... If the user specifies an ill-aligned clear rectangle,
does this code clear a slightly larger, well-aligned rectangle? In other words,
will this clear pixels outside the user-specified clear rectangle? Local
inspection of the code suggests so to me. But my global understanding of
these codepaths is vague.
More information about the mesa-dev
mailing list