FYI Re: wined3d_mutex

[Max TenEyck Woodbury]

On 03/17/2014 06:28 AM, Stefan Dösinger wrote:
> -----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.
>
OK.  A new technique I probably need to learn.  Please tell me about it.

I was thinking that 'top' has some ability to monitor process wait
states and I was going to start from there.

>> 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.
>
Well, at least as fine as native.  Finer might be safer since there is
little besides direct examination of the native execution stream (a big
NONO!) that assures that all grain boundaries have been identified.

> 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.
>
OK.  I believe you, but exactly what kind of lock is it and how did you
go about identifying it?  The fact that 'we' hold it during the call
backs is something that bothered me.  I also noted that 'we' sometimes
take it out twice which also makes me think its use is rather
superficial.

> 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.
>
:-) No bet.  Even good coders have a bit of trouble with that kind of
thing, and while they do have some of those, they also have some of the
other kind.

> 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).
>
I'm not sure I'm following this properly, particularly the part about
the main thread knowing about commands scheduled on other threads...

max