On Thu, 16 Dec 2021 at 04:46, Conor McCarthy cmccarthy@codeweavers.com wrote:
December 16, 2021 4:18 AM, "Henri Verbeet" hverbeet@gmail.com wrote: Correct behaviour is a bit tricky here. It isn't correct for a game to write a descriptor from two threads or write it from one while reading it from another. The only reason it works is because the descriptors are identical and/or in Windows drivers the internal descriptor data structure makes them compatible somehow. But this isn't the case with vkd3d.
On the one hand, some games may not work without the config option. On the other hand, most or possibly all games except SotTR will run with unnecessary mutex operations unless a config option is used, though the performance impact will only be significant if descriptor copies per frame are in the hundreds or the thousands, probably. But the difference will be greater on a high spec GPU because the mutexes add a fixed CPU overhead not improved by a faster GPU.
Right, "correct" in a Wine context essentially means something along the lines of "applications that work on Windows work equally well on Wine".
- Is the actual issue here the number of calls to
pthread_mutex_lock(), particularly when called from d3d12_device_CopyDescriptors()? Or is something else going on here? In case of the former, we could perhaps mitigate that by doing moving those calls outside of the loops in d3d12_device_CopyDescriptors().
Yes, pthread_mutex_lock() is the issue. I don't see a way to do this outside the loop because the mutex changes per descriptor.
Could we just lock all of them pre-emptively? There are only 8; in theory we'd be ahead after copying more than that number of descriptors, in terms of locking overhead at least.
We could also consider moving to a single mutex for descriptor updates. IIRC the current scheme was introduced for Shadow of the Tomb Raider, but it seems we no longer care about that application as much...