On 10/30/2013 06:43 AM, Paul Berry wrote:
On 30 October 2013 00:00, Eric Anholt <e...@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@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
