[PATCH 23/35] wined3d: Use separate locks for deferred contexts.

[Henri Verbeet]

On Tue, 19 Oct 2021 at 16:28, Jan Sikorski <jsikorski at codeweavers.com> wrote:
> > On 19 Oct 2021, at 15:56, Henri Verbeet <hverbeet at gmail.com> wrote:
> > On Fri, 15 Oct 2021 at 14:27, Jan Sikorski <jsikorski at codeweavers.com> wrote:
> >> ---
> >> dlls/wined3d/cs.c              |  23 +++--
> >> dlls/wined3d/device.c          | 152 ++++++++++++++++-----------------
> >> dlls/wined3d/wined3d_private.h |  17 ++++
> >> 3 files changed, 107 insertions(+), 85 deletions(-)
> >>
> > Is that safe at this stage? For example, calling
> > d3d11_device_context_OMGetRenderTargets() on a deferred context would
> > now use wined3d_mutex_lock()/wined3d_mutex_unlock(), while calling
> > d3d11_device_context_OMSetRenderTargets() for that same context would
> > use the lock specific to that context.
>
> Right, that’s a good point (and also why I previously thought of taking a shared lock on the global mutex when locking deferred contexts, which somehow escaped me later). Although with getters I suppose it’s mostly a matter of getting back a consistent view of the state.
> On the other hand, do we even expect that to be thread safe? MS docs say (in the Introduction to Multithreading in Direct3D 11) that the use of a device context is supposed to be externally synchronized. Other parts of the multi threading section also indicate that command list generation is single threaded only. If that’s the case, I guess we could drop device context locking altogether, or do it for the immediate context only, as at least Direct3D 10 still needs it.
>

The concern would be callers getting back a consistent view of the
state, yes. I'm not sure what Direct3D 10/11 actually guarantees. It's
perhaps worth pointing out though that it's not unheard of for
applications to depend on what the implementation does in practice,
instead of on what the documentation guarantees.