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

[Chris Forbes]

Vedran,

Just to add a bit more context -- programming a strange viewport
causes us to turn off guardband clipping. I haven't measured the
impact on dota2, but when it was initially enabled it was a nice win
for some other games.

-- Chris

On Thu, Oct 31, 2013 at 3:38 AM, Chad Versace
<chad.versace at linux.intel.com> wrote:
> On 10/30/2013 06:43 AM, Paul Berry wrote:
>>
>> 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:
>>
>
>> - 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.
>
>
> Disregard the counterintuitive behavior I observed until further notice.
> Last night, Eero informed me that the microbenchmark's javascript was
> written badly, which produced false framerate results due to synchronization
> issues between Chrome's Webkit process and GPU process. I plan to fix the
> javascript issues and re-test.
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev