The logic iterates over param[] which contains pointers to
uniform storage set during linking (see
link_assign_uniform_locations()).
The pointers are unique and it should be impossible to find
matching entries.
I couldn't find any regressions with test system. In addition
I tried several benchmarks on HSW and none hit this.
I'm hoping to remove this optimization attempt. This is the only
bit that depends on knowing about the actual storage during
compilation. All the rest deal with just relative push and pull
locations once the actual filling of pull_param[] is moved
outside the compiler just as param[]. (Filling pull_param is
based on the pull locations and doesn't need to be inside the
compiler).
Any thoughts?
Signed-off-by: Topi Pohjolainen <topi.pohjolai...@intel.com>
CC: Ian Romanick <ian.d.roman...@intel.com>
CC: Kenneth Graunke <kenn...@whitecape.org>
CC: Eric Anholt <e...@anholt.net>
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index cf62ed9..bb62fef 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -774,6 +774,8 @@ vec4_visitor::move_push_constants_to_pull_constants()
}
if (matches == 4) {
+ unreachable("Values in param[] are unique, match is
impossible");
+ exit(1);
pull_constant_loc[i / 4] = j / 4;
break;
}
--
2.5.0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
