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

[Giovanni Mascellani]

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).

> Some brief testing suggests this is incorrect, though. Native will let 
> you do this:
> 
> void func(float a) {}
> 
> void func(float1 a) {}
> 
> It will also accept "row_major float4x4" alongside "column_major 4x4". 
> Even worse, though, it will accept "float4x4" alongside "column_major 
> 4x4", "float" alongside "const float" alongside "volatile float", and 
> even the following:
> 
> void func(float a) {}
> 
> typedef float myfloat;
> void func(myfloat a) {}
> 
> It won't accept "float" alongside "in float", though. That's too far. 
> But it will accept "float" alongside "inout float" alongside "out float".
> 
> Of course, attempting to actually *call* func in any of these cases 
> results in an "ambiguous function call" error. So it's not completely 
> insane.

I think it is pretty insane anyway, especially given that even in the 
case of float vs float1 I don't think you have any mean at all to 
differentiate between the two. So, as soon as you define both of them, 
there is no way to call either, even with explicit casts.

Thanks, Giovanni.