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

[Steve Lhomme]

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

Even though the discussion is heated (fitting with the weather here) I 
don't mind. I learned some stuff and it pushed me to dig deeper. I can't 
just accept your word for it. I need something solid if I'm going to 
remove a lock that helped me so far.

So I'm currently tooling VLC to be able to bring the decoder to its 
knees and find out what it can and cannot do safely. So far I can still 
see decoding artifacts when I don't a lock, which would mean I still 
need the mutex, for the reasons given in the previous mail.