In a similar fashion, I think it also introduces race conditions between the submission fences and the signaled semaphores: the fences are signaled by the GPU directly as soon as it has executed the submission and signaled all the events, but the thread might not have processed the signals yet and not have updated the CPU-visible semaphore values to the values that they should have.
yes, maybe it can be made fully correct only if we handle all the d3d12 fences on the winevulkan . win32u side, both shared and not, also knowing d3d12 queue configuration and submits... which maybe pulls a noticable share of d3d12 translation layer implementation there. This is unlikely much appealing and shared fences implementation will have to have some trade offs, which however worked in practice so far, given limited usage of those.
Overall I'm starting to wonder whether it is a good idea to add all this logic now, and end up with a half assed implementation which will never be able to implement every thing we need properly. It seems to me that the only option here is to have host Vulkan driver support for rewinding.
Not only for rewindind per se but a bit of other timeline semaphores constraints. That would be great not only for shared fences but for d3d12 local fences implementation but AFAIU that meets issues on the Vulkan speccing side (as far as I heard that meets some opposition because Vulkan is supported on a wide range of hardware and on some that is hard to implement; but don't quote me on that, I am not up to date with those details). But I guess we will unlikely have that done anytime soon, and even if that is specced chances that will be an optional extension and that will be limited to a subset of GPU hardware / drivers. While that is not so extensively used within rendering workflow, it is used relatively often in modern games. So maybe a solution with known limitations but generally working is still a good call.