On Fri, 17 Dec 2021 at 14:58, Conor McCarthy cmccarthy@codeweavers.com wrote:
December 17, 2021 10:33 PM, "Henri Verbeet" hverbeet@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.