On 10/19/22 07:57, Francisco Casas wrote:
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.
Heh, neither did I until I started testing some of the related corner cases :-)
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().
Yeah. My take is that most of that simplification probably belongs in this patch rather than that one.