[Mesa-dev] [PATCH] [rfc] spirv: work around doom shaders having load/store to sampler types

Jason Ekstrand jason at jlekstrand.net
Fri Dec 23 14:46:42 UTC 2016

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" <airlied at gmail.com> wrote:

From: Dave Airlie <airlied at 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 <airlied at 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_
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
    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);

mesa-dev mailing list
mesa-dev at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161223/18da4c45/attachment.html>

More information about the mesa-dev mailing list