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

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 4:46 PM, Ian Romanick <idr at freedesktop.org> wrote:

> On 12/23/2016 06:46 AM, Jason Ekstrand wrote:
> > 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.
>
> Is this something the SPIR-V validator would flag?
>

Ideally, yes.  Unfortunately, I'm not sure how much SPIR-V validation
actually gets done.  Also, it's kind-of a weird corner of the spec that's
not as clear-cut as one would like it to be.  I interpreted it as "No, you
can't store a sampler in a variable.  That's silly" and fixed glslang.  I
believe I did try to get the spec fixed and it didn't really go anywhere.

--Jason


> > On Dec 22, 2016 22:57, "Dave Airlie" <airlied at gmail.com
> > <mailto:airlied at gmail.com>> wrote:
> >
> >     From: Dave Airlie <airlied at redhat.com <mailto: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
> >     <mailto: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_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 at lists.freedesktop.org <mailto:mesa-dev at lists.
> freedesktop.org>
> >     https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >     <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>
> >
> >
> >
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170120/a2536018/attachment.html>