> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Steve Lhomme > Sent: Tuesday, August 11, 2020 10:06 AM > To: ffmpeg-devel@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-boun...@ffmpeg.org> On Behalf Of > >> Steve Lhomme > >> Sent: Tuesday, August 11, 2020 6:35 AM > >> To: ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
