On 13/09/17 12:57, Dave Airlie wrote:
From: Dave Airlie <airl...@redhat.com>
This gets the ssao demo from 400->440 fps on radv with the
previous patch.
Now the demo does a 0->32 loop across a ubo with 32 members,
I don't know if we still have that sort of information available
about the UBO in question at this stage. Maybe someone more
familiar with spir-v/nir can tell if we can access that info
then we can force a loop unroll like we do for var arrays.
Signed-off-by: Dave Airlie <airl...@redhat.com>
---
src/compiler/nir/nir_opt_loop_unroll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
b/src/compiler/nir/nir_opt_loop_unroll.c
index 79d04f9..6158d58 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -34,7 +34,7 @@
* loops that would unroll with GLSL IR fail to unroll if we set this to 25 so
* we set it to 26.
*/
-#define LOOP_UNROLL_LIMIT 26
+#define LOOP_UNROLL_LIMIT 96
The main reason these limits exist is because they existed in GLSL IR.
In GLSL IR the chosen limits reflect an issue with the speed at which
the loop opt pass can run rather than issue with the size of the shader
output so there isn't any reason I've seen to keep them so low. On the
other-hand maybe detecting UBO indexing would be enough in most case
anyway.
/* Prepare this loop for unrolling by first converting to lcssa and then
* converting the phis from the loops first block and the block that follows
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
