--
v2: vkd3d-shader/hlsl: Map the colour output for ps_1_* to r0.
vkd3d-shader/hlsl: Rewrite the register allocator to allow allocating in multiple passes.
vkd3d-shader/hlsl: Avoid leaking the allocator register map in allocate_const_registers().
vkd3d-shader/hlsl: Rename struct liveness to struct register_allocator.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/168
> FWIW, it's not necessarily that everything would go directly into v_s_i (clearly HLSL wouldn't), but sm1 and sm4 at least would. Contrary to what Henri said, I was actually of the impression that sm6 could deal directly with v_s_i without adding too much? Besides new opcodes and interfaces, I thought we didn't need much more than a new "SSA" register type.
Well, there's the shader I/O signature and register normalisation work that Conor is currently working on, for example. I don't know if I'd qualify that as "much more", but it's essentially adapting the TPF frontend and SPIR-V backend to accommodate the DXIL frontend. It doesn't touch the representation of individual instructions much, so in that sense, sure. (Also, it ends up actually simplifying the SPIR-V backend by moving some transformations that aren't needed for DXIL to the common IR level where they're easier to do...)
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31899