> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Steve Lhomme > Sent: Saturday, August 8, 2020 7:10 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
[...] > > > > Hi Steven, > > Hi, > > > A while ago I had extended D3D11VA implementation to support single > > (non-array textures) for interoperability with Intel QSV+DX11. > > Looking at your code, it seems you are copying from an array texture to a > single slice texture to achieve this. With double the amount of RAM. > It may be a design issue with the new D3D11 API, which forces you to do With D3D11, it's mandatory to use a staging texture, which is not only done in my code but also in the original implementation (hwcontext_d3d11va.c) https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_d3d11va.c > that, but I'm not using that API. I'm using the old API. I'm not sure whether I understand what you mean by this. To my knowledge there are two DX hw context implementations in ffmpeg: - DXVA2 - D3D11VA I'm not aware of a variant like "D3D11 with old API". Could you please elaborate? > > > Hence, I don't think that your patch is the best possible way . > > Removing locks and saying "it works for me" is neither a correct solution. How did you come to the conclusion that I might be working like this? > the very least the locks are needed inside libavcodec to avoid setting DXVA > buffers concurrently from different threads. It will most likely result in > very > bad distortions if not crashes. Maybe you're only using 1 decoding thread > with DXVA (which a lot of people do) so you don't have this issue, but this is > not my case. I see no point in employing multiple threads for hw accelerated decoding. To be honest I never looked into or tried whether ffmpeg even supports multiple threads with dva2 or d3d11va hw acceleration. > Also ID3D10Multithread::SetMultithreadProtected means that the resources > can be accessed from multiple threads. It doesn't mean that calls to > ID3D11DeviceContext are safe from multithreading. And my experience > shows that it is not. In fact if you have the Windows SDK installed and you > have concurrent accesses, you'll get a big warning in your debug logs that you > are doing something fishy. On WindowsPhone it would even crash. This is > how I ended up adding the mutex to the old API > (e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86). > > The documentation for ID3D11DeviceContext is very clear about that [1]: > "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. In fact, I had researched this in-depth, but I can't tell much more without looking into it again. The patch I referenced is working in production on thousands of installations and tested with many different hardware and driver versions from Nvidia, Intel and AMD. 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".
