-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-03-15 21:17, schrieb Max TenEyck Woodbury:
If anybody has an idea about what might be causing these delays, please tell me.
Sorry, no idea :-( . Maybe perf or oprofile show something.
Note that my review of the use of this mutex indicates that it is of very questionable value. In my opinion it should be replaced by a set of read/write locks built into the individual data structures.
I have to give the infamous answers "it depends" and "this needs tests". It's best to use the same lock granularity as native, everything else is asking for trouble.
My very hacky testing suggests that native does not do any locking unless D3DCREATE_MULTITHREADED is passed. Applications can still call d3d from multiple threads without that flag, but then they have to do their own locking. If they don't, the application crashes sooner rather than later.
Ddraw has one global DLL lock. That can be demonstrated easily with the various enum callbacks in the API. Native does not bother to release the lock when calling the application callback.
I suspect d3d8/9 has a per device lock, but I have not done any testing to confirm this. IDirect3DResource9::SetPrivateData is your ticket to finding out. It's the only way you can make native d3d8/9 call your code (IUnknown::AddRef/Release, thanks to D3DSPD_IUNKNOWN). Maybe Microsoft was careful enough to release the lock before calling those methods, but I'd bet a beer that they weren't.
The other thing to consider wrt locking is the multithreaded command stream. Some fields need synchronization. We can't use the wined3d lock for that. My general goal is to avoid sharing resource / device / whatever fields between the main and worker thread as much as possible, and if I do (e.g. (sub)resource.locations) set up CS and resource idle waits in such a way that the main thread knows no command is scheduled or being executed while it operates on those fields. Right now there are plenty of bugs in my preview code (e.g. struct wined3d_buffer.flags).