Hello,
On 19-10-22 01:52, Zebediah Figura (@zfigura) wrote:
type_contains_only_numerics() (and/or the interaction with hlsl_types_are_componentwise_compatible()) felt weird to me, so I ended up going through and seeing if it's really necessary.
implicit_compatible_data_types() handles the following cases:
- 1x1 to/from vector/matrix — these are already numeric
- array to array element — this actually shouldn't be allowed implicitly (currently broken).
- array to/from vector/matrix — shouldn't be allowed implicitly (currently broken).
- array to array — this should be allowed only if the types match (currently broken), and so should fall under hlsl_types_are_componentwise_compatible().
- vector to vector — already numeric
- vector to/from matrix — already numeric
Oh, interesting, I didn't realize that there were currently broken implicit casts, I simply assumed they were correct. I added implicit_compatible_data_types() for the sake of making it "more correct", but I will check this in more detail.
compatible_data_types() handles the following cases:
- 1x1 to anything — we do actually need type_contains_only_numerics() for this
- numerics to 1x1 — already numeric
- array to array element — this *is* legal with objects, and we shouldn't guard it with type_contains_only_numerics()
- array to array/struct — same, and this should fall under hlsl_types_are_componentwise_compatible()
- numeric to array/struct — should fall under hlsl_types_are_componentwise_compatible() I think?
- matrix to matrix — already numeric
The summary, and upshot, is
(1) we only actually need type_contains_only_numerics() for (explicit!) scalar-to-struct/array broadcasts
(2) we can replace some of the existing cases with hlsl_types_are_componentwise_{equal,compatible}() and thereby simplify (implicit)_compatible_data_types() a bit.
I think I understand what you mean. I simplified compatible_data_types() in this patch (in the continuation of the series):
https://gitlab.winehq.org/fcasas/vkd3d/-/commit/838e575fdde5b15cfde785250d84...
but I didn't think I could do the same for implicit_compatible_data_types().
We probably can defer some of the fixes (broken implicit conversions listed above) to after this patch, honestly, but if it's simple enough doing it first wouldn't be bad either.
I will work on these fixes now.
One other thing I'd request, as long as we're modifying this code—can we rename "t1" and "t2" to "src" and "dst", so this is easier to read? (Ideally put that commit first, too.)
Okay.