[PATCH vkd3d v2 3/5] vkd3d-shader/hlsl: Parse explicitly typed texture types.

[Matteo Bruni]

On Fri, Oct 8, 2021 at 6:44 PM Zebediah Figura (she/her)
<zfigura at codeweavers.com> wrote:
>
> On 10/8/21 03:41, Giovanni Mascellani wrote:
> > Hi,
> >
> > Il 07/10/21 18:19, Zebediah Figura (she/her) ha scritto:
> >> They don't behave exactly the same, though. In particular,
> >> compare_param_hlsl_types() will count "float" as equal to "float1",
> >> and "row_major float4x4" as equal to "column_major float4x4".
> >
> > Ah, ok, didn't think of that. I am not sure that the compatibility of
> > function overloads is regulated by an equivalence relation, so I am not
> > sure this approach can really work, but I guess it's ok to postpone this
> > problem until we want to really fix it (which probably means until we
> > find a shader that depends on it).
>
> I think the compatibility isn't, no, and I'm sure this code was written
> with the idea in mind that it could be used to look up the correct
> overloads for a call. Which it can't, really.

Yep, that's right. Unfortunate.

> Frankly I'm not sure there's much reason to use an rbtree for function
> overloads, at least not given the way we implement intrinsics now. So
> maybe compare_param_hlsl_types() really doesn't need to exist, and
> hlsl_types_are_equal() is enough.

That sounds likely, given the above. Up to you to decide if (or when)
to simplify function overloads storage.