[FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Steve Lhomme
> Sent: Monday, August 10, 2020 2:15 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
> copies are done before submitting them
> 

> > @Steven
> 
> My name is Steve.

I apologize for that.

> My change in e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86 is optional. So
> much that it even requires to use the creator helper function to make sure
> the mutex is properly initialized to an empty value and retain backward
> compatibility. If you don't want to use many threads you can safely ignore
> this field.

I thought you had reviewed my code, because you said that it was you 
who had added the locks that I have removed. I just took a look at your commit 
e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86 and I can say that those
are not the locks that I have removed. 
So you are actually the wrong address for the lock removal, you've just 
thrown yourself in the line ;-)

But the DX11 subject still needs some clarification...

> >>>> The documentation for ID3D11DeviceContext is very clear about that
> [2]:
> >>>> "Because each ID3D11DeviceContext is single threaded, only one
> >>>> thread can call a ID3D11DeviceContext at a time. If multiple
> >>>> threads must access a single ID3D11DeviceContext, they must use
> >>>> some synchronization mechanism, such as critical sections, to
> >>>> synchronize
> >> access to that ID3D11DeviceContext."
> >>>
> >>> Yes, but this doesn't apply to accessing staging textures IIRC.
> >>
> >> It does. To copy to a staging texture you need to use
> >> ID3D11DeviceContext::CopySubresourceRegion().
> >
> > Correct. And with DX11 and using SetMultithreadProtected it is legal
> > to call this from multiple threads without synchronization.
> 
> No. I already explained it and pointed to the Microsoft documentation [1].
> SetMultithreadProtected relates to ID3D11Device.

No, that's exactly wrong. You need to re-read. ID3D11Device is thread-safe
by default. You can read that everywhere throughout the documentation.

SetMultithreadProtected initially didn't even have a D3D11 interface.
The documentation also didn't tell anything about it. There was only
the DX10 documentation for this.

But SetMultithreadProtected in fact has the effect of protecting 
the methods from ID3D11DeviceContext (not device).
Like I explained several times already.


Luckily I've just seen that there has been a change meanwhile.
The undocumented behavior has finally been made public by
adding a DX11 version of SetMultithreadProtected
(which does the same as what happens when you use the DX10
version with DX11)

https://docs.microsoft.com/en-us/windows/win32/api/d3d11_4/nn-d3d11_4-id3d11multithread

Now: Read the docs!

PS: I need to say that your way of discrediting my statements
was not very respectful.

Kind regards,
softworkz