[PATCH vkd3d v2 4/4] vkd3d: Move atomic descriptor operations behind a config option.

[Henri Verbeet]

On Thu, 16 Dec 2021 at 04:46, Conor McCarthy <cmccarthy at codeweavers.com> wrote:
> December 16, 2021 4:18 AM, "Henri Verbeet" <hverbeet at 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...