<div dir="ltr">On 30 October 2013 00:00, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One of the things I was wondering about for dota2 performance was<br>
whether missing the fast clears was a big performance hit --<br>
particularly with the fips numbers indicating a lot of time spent in<br>
clears.  However, applying this patch:<br>
<br>
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp b/src/mesa/drivers/dr<br>
index d1933ce..2843ed6 100644<br>
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp<br>
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp<br>
@@ -156,7 +156,11 @@ is_color_fast_clear_compatible(struct brw_context *brw,<br>
       if (color->f[i] != 0.0 && color->f[i] != 1.0) {<br>
          perf_debug("Clear color unsupported by fast color clear.  "<br>
                     "Falling back to slow clear.\n");<br>
-         return false;<br>
+         printf("SMASHING FAST CLEAR %f %f %f %f %dx%d\n",<br>
+                color->f[0], color->f[1], color->f[2], color->f[3],<br>
+                brw->ctx.DrawBuffer->_Xmax - brw->ctx.DrawBuffer->_Xmin,<br>
+                brw->ctx.DrawBuffer->_Ymax - brw->ctx.DrawBuffer->_Ymin);<br>
+         return true;<br>
       }<br>
    }<br>
    return true;<br>
<br>
produced a lot of output:<br>
<br>
SMASHING FAST CLEAR 0.501961 0.501961 0.501961 1.000000 1440x900<br>
SMASHING FAST CLEAR 0.901961 0.901961 0.901961 1.000000 64x64<br>
SMASHING FAST CLEAR 0.501961 0.501961 0.501961 1.000000 1440x900<br>
SMASHING FAST CLEAR 0.901961 0.901961 0.901961 1.000000 64x64<br>
<br>
but no performance difference:<br>
<br>
anholt@yvain:/home/anholt% ministat before after<br>
x before<br>
+ after<br>
+--------------------------------------------------------------------------+<br>
|   x       x       x   +    +           +   +   *       x                +|<br>
||__________________M___A_|_________________AM__|____________|             |<br>
+--------------------------------------------------------------------------+<br>
    N           Min           Max        Median           Avg        Stddev<br>
x   6         13.51         13.64         13.55         13.56   0.056568542<br>
+   6         13.56         13.68         13.61     13.606667   0.042739521<br>
No difference proven at 95.0% confidence<br>
<br>
(test was done with the printf run only a single time)<br></blockquote><div><br></div><div>Hmm, interesting.  A few thoughts:<br><br></div><div>- 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.<br>
<br></div><div>- 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.<br><br></div><div>- 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.)<br>
<br></div><div>- With this patch applied, does the FIPS data still indicate a lot of time spent doing clears?<br><br></div><div>- 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).<br>
</div></div></div></div>