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

Henri Verbeet hverbeet at gmail.com
Wed Aug 11 08:15:32 CDT 2021


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.



More information about the wine-devel mailing list