On Tue Jan 31 21:31:28 2023 +0000, Francisco Casas wrote:
What I am currently doing is to have each regset represent a single letter used for register reservations (and thus, in the assembly), which also matches the "space" that is used for calculating the register offsets of the object components within a struct. So, SM1 would be mapping samplers (and the textures that result from combining sampler+texture, in following patches) to `HLSL_REGSET_S`, while for SM4 we would be mapping samplers to `HLSL_REGSET_S` and textures to `HLSL_REGSET_T`. This mapping is done now in `hlsl_type_get_regset()`.
SM1: Texture -> HLSL_REGSET_S -> D3DSPR_SAMPLER Sampler -> HLSL_REGSET_S -> D3DSPR_SAMPLER SM4: Texture -> HLSL_REGSET_T -> VKD3D_SM4_RT_RESOURCE Sampler -> HLSL_REGSET_S -> VKD3D_SM4_RT_SAMPLER UAV -> HLSL_REGSET_U -> VKD3D_SM5_RT_UAVIf I am understanding correctly, based on your last comment, you are suggesting doing:
SM1: Texture -> HLSL_REGSET_RESOURCE -> D3DSPR_SAMPLER Sampler -> HLSL_REGSET_SAMPLER -> D3DSPR_SAMPLER SM4: Texture -> HLSL_REGSET_RESOURCE -> VKD3D_SM4_RT_RESOURCE Sampler -> HLSL_REGSET_SAMPLER -> VKD3D_SM4_RT_SAMPLER UAV -> HLSL_REGSET_UAV -> VKD3D_SM5_RT_UAVwhich means, always assigning each type to the same regset, regardless of the shader model, deferring the mapping to a unique register type until writing the binary. But if we do this, we would require an intermediate mapping from `HLSL_REGSET_*` to the letters used for register reservations and the different register spaces used for calculating offsets. Because, in SM1, sampler and texture indexes are not separated.
We shouldn't even have sampler variables left over by the time we get to sm1.
But if we do this, we would require an intermediate mapping from HLSL_REGSET_* to the letters used for register reservations and the different register spaces used for calculating offsets.
But we need an intermediate mapping from HLSL_REGSET_* to backend-specific register type enums anyway. Why does it matter how we map hlsl types to regsets?