FYI Re: wined3d_mutex

Stefan Dösinger stefandoesinger at gmail.com
Mon Mar 17 05:28:52 CDT 2014


-----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).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTJs5kAAoJEN0/YqbEcdMwpMkP/jy5crUdlP6NOUjhOKPR8fd0
Hoy8bdxgkexPHgRFm7hDgFfSrfEDvOKRuwgD8cpFC+AtC1pwMdstPo7/VrwI7CWH
diNyytRt+lvK74BR0zyXeTW7KAkw2+doCc28o8IWSEn9HtexdYmnlyBLRoMwHT4/
WRCtQb+mriLctnMRpp3LVOTJhwESTA74heSOsE11YtkqRYflMlKh7/8iLSHnRt6l
FkHyY1ajLYkIB8NsbUWkXXTHkG9VC59pVpkQvOBdKQDXiEYCELNR7FTP9OqqHt2U
DtG8LSUvuSRjMuL9ozBU5aF/EFeevIXjeMyi30f5mb2cT+yGDP/P/QKZNXyDVqD0
J95FvvIuitw5iLAQ1RzNQpMvHgwMsZZ0YpHCW+8hpAmI30HO7sHpOREXmCGt6OfV
GZlmSIVP7fDqF2tF3SaFEABFd6XNeVj4APG1LgFOeE16Jl5RYaIqfMYCCWjyi5YQ
vsa1GY1cIp4/ZkdG/nZvVOHYhqv6eTuske2QdzpLHR5nvhY3KB8UnPHzWwatHjkH
e6FJquUPNbqzgEDgK0w/HJ9X/Kq9StKYC6uUDi0bkHrJ8ouDxcySFM9nNsMyfWix
S0SerY5h8FfVdmk8MAV4xu+j3N87eorsMMnTJj40LcTQU6G0vCvAMYIT7PqgpaVf
68CqGerjMAzLUl3RJ3ng
=vlfU
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list