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

[Henri Verbeet]

On Fri, 17 Dec 2021 at 14:58, Conor McCarthy <cmccarthy at codeweavers.com> wrote:
> December 17, 2021 10:33 PM, "Henri Verbeet" <hverbeet at gmail.com> wrote:
> > If the issue is that the application copies small numbers of
> > descriptors each time, that should be easy to detect. We could use the
> > current path with individual locks for each descriptor in that case.
> > I'm not sure whether it's worth doing that or not though; for
> > applications copying large numbers of descriptors like Control, always
> > using a single mutex is likely the more efficient option.
>
> I think it's not worth it at the moment. We would lock 8 descriptors at once for games which don't need atomic descriptors, but not for the only game which does. If performance becomes a problem in the future for the single mutex we can add a spinlock to each descriptor at a cost of 4 bytes per descriptor.

Sticking with the single mutex certainly seems fine to me for the moment.

Note though that the cost of adding a spinlock to each descriptor is a
fair bit more than the 4 bytes of storage; atomic operations aren't
free, even when the lock is uncontested. Essentially, in the
uncontested case, the cost of taking the 8 (or whichever number we
pick) mutexes would get amortised over the number of descriptors being
updated, and shouldn't be all that much worse than the cost of taking
8 spinlocks. On the other hand, taking a spinlock per descriptor would
add a (somewhat) fixed overhead per descriptor being updated.