On Mon Feb 6 13:58:18 2023 +0000, Francisco Casas wrote:
I mean we shouldn't have HLSL_TYPE_SAMPLER variables left over. That's
what my (out-of-tree) patches accomplish by lowering "separate" HLSL_IR_RESOURCE_LOAD to "combined" HLSL_IR_RESOURCE_LOAD instructions. I.e. removing the "sampler" variable from the instruction. Ah yes, I even include this patch in [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) with the required rebasing. But even if these are textures, in SM1 they have to be allocated using the `s` registers.
I realize, by the way, the current code doesn't really work like this
(cf. the object_types global array), but I think the current code is broken for sm1 anyway. Ah! Yep, samplers are not being turned into textures now, and in fact, on the following master6 patches (including sm1 resource loads) I keep regular samplers as HLSL_TYPE_SAMPLER and only combined samplers are HLSL_TYPE_TEXTURE, and this works fine, and matches the signatures in the CTAB.
What I'm trying to say is that the letter used in disassembly simply isn't that meaningful *or* communicative, and we shouldn't be relying on it for internal naming or design. SM1's "s" variables aren't equal to sm4's "s" *or* "t". They are closer to the latter, though. On the other hand, SM1's "t" variables are completely different from SM4's "t" (they're closest to sm4's "v"). Accordingly I don't think it makes much sense to map HLSL types to regsets based on the disassembly letter, and I definitely don't think it makes sense to name the regset enum elements based on disassembly letter.