This applies on top of !672, the last three commits belong here.
Here we compute additional "synthetic" loops that will be used to implement non-trivial forward edges using (possibly conditional) `break` instructions.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/698
On Fri Mar 8 09:47:03 2024 +0000, Giovanni Mascellani wrote:
> Yeah, right. Even for SM6 the current code is likely to produce bad
> results, because AFAIU many signature elements can be merged in a single
> one using `register_count`. I think the appropriate action right now is
> to emit the signature only for SM4-5, and leave the rest to the future
> if the need will arise. I will submit a MR for that.
Mmh, I'm probably confused about SM6. At least for the moment these metadata are meant to represent whatever is stored in the DXBC container, so it shouldn't change anything with SM6. I'll just disable for SM1-3.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/553#note_63977
On Fri Mar 8 09:47:03 2024 +0000, Henri Verbeet wrote:
> Should we output input/output signatures for d3dbc shaders? Currently we
> do, and there's something to be said for that, but it does complicate
> things in a couple of ways:
> - We wouldn't be able to assemble such signatures in any meaningful
> way for d3dbc targets. I.e., the assembler would largely just have to
> ignore them.
> - The register names are slightly different. E.g. ps_2_0 has t#
> texture coordinate inputs and oC# colour outputs.
Yeah, right. Even for SM6 the current code is likely to produce bad results, because AFAIU many signature elements can be merged in a single one using `register_count`. I think the appropriate action right now is to emit the signature only for SM4-5, and leave the rest to the future if the need will arise. I will submit a MR for that.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/553#note_63974