[Mesa-dev] Interesting i965 behavior: more fast color clears not helping dota2

[Paul Berry]

On 30 October 2013 00:00, Eric Anholt <eric at anholt.net> wrote:

> One of the things I was wondering about for dota2 performance was
> whether missing the fast clears was a big performance hit --
> particularly with the fips numbers indicating a lot of time spent in
> clears.  However, applying this patch:
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> b/src/mesa/drivers/dr
> index d1933ce..2843ed6 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> @@ -156,7 +156,11 @@ is_color_fast_clear_compatible(struct brw_context
> *brw,
>        if (color->f[i] != 0.0 && color->f[i] != 1.0) {
>           perf_debug("Clear color unsupported by fast color clear.  "
>                      "Falling back to slow clear.\n");
> -         return false;
> +         printf("SMASHING FAST CLEAR %f %f %f %f %dx%d\n",
> +                color->f[0], color->f[1], color->f[2], color->f[3],
> +                brw->ctx.DrawBuffer->_Xmax - brw->ctx.DrawBuffer->_Xmin,
> +                brw->ctx.DrawBuffer->_Ymax - brw->ctx.DrawBuffer->_Ymin);
> +         return true;
>        }
>     }
>     return true;
>
> produced a lot of output:
>
> SMASHING FAST CLEAR 0.501961 0.501961 0.501961 1.000000 1440x900
> SMASHING FAST CLEAR 0.901961 0.901961 0.901961 1.000000 64x64
> SMASHING FAST CLEAR 0.501961 0.501961 0.501961 1.000000 1440x900
> SMASHING FAST CLEAR 0.901961 0.901961 0.901961 1.000000 64x64
>
> but no performance difference:
>
> anholt at yvain:/home/anholt% ministat before after
> x before
> + after
>
> +--------------------------------------------------------------------------+
> |   x       x       x   +    +           +   +   *       x
>  +|
> ||__________________M___A_|_________________AM__|____________|
> |
>
> +--------------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stddev
> x   6         13.51         13.64         13.55         13.56   0.056568542
> +   6         13.56         13.68         13.61     13.606667   0.042739521
> No difference proven at 95.0% confidence
>
> (test was done with the printf run only a single time)
>

Hmm, interesting.  A few thoughts:

- I wonder if the 64x64 image is small enough that fast clear is a net loss
(because it requires extra bookkeeping).  Perhaps this would be a benefit
if it were only applied to the 1440x900 buffer.

- Chad told me on Monday about some counterintuitive stuff he was seeing
where fast clear appeared to be slower than slow clear.  I don't recall the
details.

- Fast color clear is only beneficial if the cleared pixels later get other
image data drawn over the top of them.  (If they don't, then the time gets
spent doing the resolve.)

- With this patch applied, does the FIPS data still indicate a lot of time
spent doing clears?

- What percentage of clears are affected by this patch?  Even with this
patch, some clears still won't take the fast path (e.g. stencil clears,
MSAA color clears, and scissored clears).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131030/6ebb4ab7/attachment.html>