On 12/04/2013 03:07 PM, Chad Versace wrote:
> 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.vers...@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.
The pre-existing !partial_clear check (visible in this patch) ought to
prevent clears with scissoring or such. AFAICT fast color clears only
happen on full buffers today.
--Ken
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
