[llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regression
Submitted by Vinson Lee
Assigned to mes..@..op.org
Description
mesa: 1eac3ae1 (master 10.6.0-devel)
$ ./bin/ext_transform_feedback-immediate-reuse-uniform-buffer -auto Probe color at (16,0) Expected: 0.062500 0.937500 0.062500 Observed: 0.000000 0.000000 0.000000 Probe color at (32,0) Expected: 0.125000 0.875000 0.125000 Observed: 0.000000 0.000000 0.000000 Probe color at (48,0) Expected: 0.187500 0.812500 0.187500 Observed: 0.000000 0.000000 0.000000 Probe color at (64,0) Expected: 0.250000 0.750000 0.250000 Observed: 0.000000 0.000000 0.000000 Probe color at (80,0) Expected: 0.312500 0.687500 0.312500 Observed: 0.000000 0.000000 0.000000 Probe color at (96,0) Expected: 0.375000 0.625000 0.375000 Observed: 0.000000 0.000000 0.000000 Probe color at (112,0) Expected: 0.437500 0.562500 0.437500 Observed: 0.000000 0.000000 0.000000 Probe color at (128,0) Expected: 0.500000 0.500000 0.500000 Observed: 0.000000 0.000000 0.000000 Probe color at (144,0) Expected: 0.562500 0.437500 0.562500 Observed: 0.000000 0.000000 0.000000 Probe color at (160,0) Expected: 0.625000 0.375000 0.625000 Observed: 0.000000 0.000000 0.000000 Probe color at (176,0) Expected: 0.687500 0.312500 0.687500 Observed: 0.000000 0.000000 0.000000 Probe color at (192,0) Expected: 0.750000 0.250000 0.750000 Observed: 0.000000 0.000000 0.000000 Probe color at (208,0) Expected: 0.812500 0.187500 0.812500 Observed: 0.000000 0.000000 0.000000 Probe color at (224,0) Expected: 0.875000 0.125000 0.875000 Observed: 0.000000 0.000000 0.000000 Probe color at (240,0) Expected: 0.937500 0.062500 0.937500 Observed: 0.000000 0.000000 0.000000 PIGLIT: {"result": "fail" }
586536a4 is the first bad commit commit 586536a4 Author: Roland Scheidegger sroland@vmware.com Date: Thu Apr 9 00:49:11 2015 +0200
gallivm: don't use control flow when doing indirect constant buffer lookups
llvm goes crazy when doing that, using way more memory and time, though there's
probably more to it - this points to a very much similar issue as fixed in
8a9f5ecdb116d0449d63f7b94efbfa8b205d826f. In any case I've seen a quite
plain looking vertex shader with just ~50 simple tgsi instructions (but with a
dozen or so such indirect constant buffer lookups) go from a terribly high
~440ms compile time (consuming 25MB of memory in the process) down to a still
awful ~230ms and 13MB with this fix (with llvm 3.3), so there's still obvious
improvements possible (but I have no clue why it's so slow...).
The resulting shader is most likely also faster (certainly seemed so though
I don't have any hard numbers as it may have been influenced by compile times)
since generally fetching constants outside the buffer range is most likely an
app error (that is we expect all indices to be valid).
It is possible this fixes some mysterious vertex shader slowdowns we've seen
ever since we are conforming to newer apis at least partially (the main draw
loop also has similar looking conditionals which we probably could do without -
if not for the fetch at least for the additional elts condition.)
v2: use static vars for the fake bufs, minor code cleanups
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
:040000 040000 3d9c36f85b3f7cf81413a06ea0454a4c035ea447 9d2ff2be20f10d6f129bc3e1a9979d2a97a37a79 M src bisect run success
Version: 10.6