On Thursday, October 10, 2013 01:04:08 PM Eric Anholt wrote:
>
> My basic comment on resource streamer: We need performance data showing
> that it is a win before we commit it. I'm not planning on reviewing the
> changes until we get that data.
Okay, I revisited the series, did some additional optimizations where the RS
was able to cut surface state emission by up to 50% but without requiring a
separate bo for cache (I need to clean it up first before re-submitting). And
here finally, some light in the end of the tunnel:
x score_glb2_7_TREX_resource_streamer_ON
+ score_glb2_7_TREX_resource_streamer_OFF
N Min Max Median Avg Stddev
x 31 68 69 69 68.774194 0.42502372
+ 31 68 69 68 68.193548 0.40160966
Difference at 95.0% confidence
-0.580645 +/- 0.210049
-0.844278% +/- 0.305419%
(Student's t, pooled s = 0.413482)
+------------------------------------------------------------+
Anyway, I realized that I have been using GLB which only samples small number
of surfaces in a shader. It's quite shortsighted. This explains why
performance results are not very apparent in those benchmarks when enabling
hw-generated binding tables.
I think the resource streamer can really shine in cases where shaders sample
much larger number of surfaces since it is able to skip uploading the binding
table data using the CPU. I'll try to experiment next with benchmarks that has
shaders requiring larger amounts of sampled surfaces. If you have suggestions
for certain benchmarks that do this, please let me know!
-abdiel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
