[PATCH vkd3d] vkd3d-shader: Skip generating SM1 array operations.

[Matteo Bruni]

On Wed, Aug 11, 2021 at 3:15 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>
> On Wed, 11 Aug 2021 at 14:49, Matteo Bruni <matteo.mystral at gmail.com> wrote:
> >
> > On Wed, Aug 11, 2021 at 2:31 PM Henri Verbeet <hverbeet at gmail.com> wrote:
> > >
> > > On Wed, 11 Aug 2021 at 13:50, Matteo Bruni <mbruni at codeweavers.com> wrote:
> > > > @@ -768,6 +768,11 @@ static void write_sm1_instructions(struct hlsl_ctx *ctx, struct vkd3d_bytecode_b
> > > >                  FIXME("Matrix operations need to be lowered.\n");
> > > >                  break;
> > > >              }
> > > > +            if (instr->data_type->type == HLSL_CLASS_ARRAY)
> > > > +            {
> > > > +                FIXME("Array operations need to be split.\n");
> > > > +                break;
> > > > +            }
> > > >
> > > Should that be a compiler error/warning instead? Arguably that would
> > > apply to FIXMEs/ERRs in compiler code in general; I think there are
> > > very few cases where we don't want those to be compiler messages
> > > instead.
> >
> > I guess that's a possibility. In general we're currently ignoring a
> > lot of error conditions caused by missing compiler features. We could
> > certainly start switching it over to spewing errors instead (or
> > better, implementing the missing features). It feels to me that we
> > will eventually want to do that for sure but maybe not right away. At
> > this point I'd push the compiler a bit further, then e.g. as soon as
> > trivial shaders start to be compiled correctly for both SM1 and SM4 we
> > can start tightening it up so that the compiler either generates
> > correct bytecode or errors out with some compilation message.
> >
> > I can certainly be convinced otherwise though.
>
> It may not be worth the effort of changing the existing FIXMEs at this
> point, but it seems more questionable to add new ones if we already
> know we'll have to replace them in the future. If the concern is that
> generating an error means that the generated code won't be returned to
> the caller we could generate a warning instead and upgrade it to an
> error later, although I'm not sure how useful invalid byte code is
> going to be to the caller.

It can be valid bytecode, although not necessarily for the HLSL that
was given as source :D

I'm sending a new patch flagging a compilation error.