On 19 Oct 2021, at 15:56, Henri Verbeet hverbeet@gmail.com wrote:
On Fri, 15 Oct 2021 at 14:27, Jan Sikorski jsikorski@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.
- Jan