Bah... It's definitely illegal. I had fix glslang myself. I have some NIR
reworks planned that would make this work "properly" but it's a bit more
complicated than this hack. That said, I'm very reluctant to fix app bugs
in our driver. There are a lot of ways apps can go wrong with Vulkan and
we don't want to start down the road of hacking around them.
On Dec 22, 2016 22:57, "Dave Airlie" <airl...@gmail.com> wrote:
From: Dave Airlie <airl...@redhat.com>
Doom appears to generate SPIR-V that loads/store samplers before
passing them to functions, this confuses NIR, but I'm not sure
it's illegal.
Workaround this by replacing the value on store with the access
chain from the src.
This gets doom a bit further.
Signed-off-by: Dave Airlie <airl...@redhat.com>
---
src/compiler/spirv/vtn_variables.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_
variables.c
index be64dd9..f6672c0 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1437,6 +1437,14 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp
opcode,
case SpvOpStore: {
struct vtn_access_chain *dest =
vtn_value(b, w[1], vtn_value_type_access_chain)->access_chain;
+
+ if (glsl_get_base_type(dest->var->type->type) == GLSL_TYPE_SAMPLER) {
+ struct vtn_value *val = vtn_untyped_value(b, w[2]);
+ dest->var = val->access_chain->var;
+ b->values[w[1]].value_type = vtn_value_type_invalid;
+ vtn_push_value(b, w[1], vtn_value_type_access_chain)->access_chain
= val->access_chain;
+ return;
+ }
struct vtn_ssa_value *src = vtn_ssa_value(b, w[2]);
vtn_variable_store(b, src, dest);
break;
--
2.7.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
