[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: Tuesday, August 11, 2020 10:06 AM
> 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
> 
> On 2020-08-11 8:58, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Steve Lhomme
> >> Sent: Tuesday, August 11, 2020 6:35 AM
> >> 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
> >
> > [...]
> >
> >>> 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
> >>
> >> OK, this is very interesting. It certainly clarifies that it's
> >> ID3D11DeviceContext related. The documentation is still sketchy though.
> >> For example ::Enter() [1] says that it enters a device critical
> >> section, not a device context critical section. So if you have
> >> multiple device context everything is blocked. This kinda defeats the use
> of multiple threads.
> >>
> >> Also this interface is not available until Windows 10 Creator Update.
> >> So for example it cannot be used on Windows 7. Maybe the D3D10
> >> version has the same effect but there's no guarantee.
> >
> > Still playing "the doubtful" is not a sincere reaction after having
> > been proven wrong.
> 
> Sorry if you seem to know all the answers already, but I don't and so I have to
> investigate.

Last year, I had literally worked this down to death. I followed every slightest
hint from countless searches, read through hundreds of discussions, driven
because I was unwilling to believe that up-/downloading of video textures with
D3D11 can't be done equally fast as with D3D9. 
(the big picture was the implementation of D3D11 support for QuickSync where
the slowdown played a much bigger role than with D3D11VA decoders only).
Eventually I landed at some internal Nvidia presentation, some talks with MS
guys and some source code discussion deep inside a 3D game engine (not a 
no-name). It really bugs me that I didn't properly note the references, but
from somewhere in between I was able to gather solid evidence about what 
is legal to do and what Is not. Based on that, followed several iterations to
find the optimal way for doing the texture transfer. As I had implemented
D3D11 support for QuickSync, this got pretty complicated because with
a full transcoding pipeline, all parts (decoder, encoder and filters) can (and
usually will) request textures. Only the latest Intel Drivers can work with
array textures everywhere (e.g. VPP), so I also needed to add support for
non-array texture allocation. The patch you've seen is the result of weeks
of intensive work (a small but crucial part of it) - even when it may not 
look like that.


> Sorry if you seem to know all the answers already

Obviously, I don't know all the answers, but all the answers I have given
were correct. And when I didn't have an answer I always respectfully 
said that your situation might be different.
And I didn't reply by implying that you would have done your work
by trial-and-error or most likely invalid assumptions or deductions.


I still don't know how you are actually operating this and thus I also cannot
tell what might or might not work in your case.
All I can tell is that the procedure that I have described (1-2-3-4) can 
work rock-solid for multi-threaded DX11 texture transfer when it's done in 
the same way as I've shown.
And believe it or not - I would still be happy when it would be  
of any use for you...

Kind regards,
softworkz