gallivm: don't use control flow when doing indirect constant buffer lookups
authorRoland Scheidegger <sroland@vmware.com>
Wed, 8 Apr 2015 22:49:11 +0000 (00:49 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Wed, 8 Apr 2015 23:32:30 +0000 (01:32 +0200)
commit586536a4e1c34725b3b38c3425db569fac0c91e9
tree92392ea54cf37be68e60f92eb207d072e470caeb
parent09e7e2016b702e2c4b79a2c01e8abc1365b4c422
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>
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
src/gallium/drivers/llvmpipe/lp_setup.c