[Mesa-dev] 10bit HEVC decoding for RadeonSI v2
christian.koenig at amd.com
Sun Feb 11 12:05:19 UTC 2018
Am 11.02.2018 um 11:35 schrieb Philipp Kerling:
> 2018-02-11 (日) の 11:02 +0100 に Christian König さんは書きました:
>> Am 09.02.2018 um 21:35 schrieb Philipp Kerling:
>>> resurrecting this thread again since there's been some progress on
>>> Kodi side.
>>>> For the EGL part, see <https://github.com/01org/libva/pull/125>
>>>> and <https://lists.freedesktop.org/archives/mesa-dev/2017-October
>>> We recently started testing vaExportSurfaceHandle support, so we
>>> have this covered soon.
>>>> I have been testing with mpv and ffmpeg; any thoughts from the
>>>> Kodi point of view would be most welcome.
>>> It generally works quite well, but we still have the unresolved
>>> vaSyncSurface problem.
>>> To recap: vaExportSurfaceHandle requires calling vaSyncSurface to
>>> sure that the decode is actually finished and the buffer is usable
>>> before rendering the frame. However, vaSyncSurface was largely
>>> unimplemented on mesa back then and it was unclear how to proceed
>>> regard to decode (VAAPI)/present (EGL+GL) synchronization.
>>> So on to the question: Is this still the case, or has there been
>>> progress on implementing vaSyncSurface in mesa? In either case, do
>>> need that support or does this syncing work implicitly somehow on
>>> I've noticed that mpv does not seem to call vaSyncSurface, although
>>> technically should.
>> Actually the mpv approach is correct.
>> Calling vaSyncSurface is unnecessary and undesired for AMD hardware
>> because it moves synchronization to the CPU while it should happen
>> the GPU and/or GPU scheduler.
>> E.g. our 3D pipeline can wait for hardware video decoding to finish
>> before starting the rendering. We even have some implementations
>> allow the 3D pipeline to start when only the first halve of the
>> is decoded etc..
>> If we don't do this the 3D pipeline runs dry between frame decoding
>> which leads to problems with power management.
> Thanks for the explanation! To verify: For AMD hardware, all of this is
> taken care of implicitly when we use the DRMPRIME buffer from
> vaExportSurfaceHandle in EGL/GL? We don't need to wait for anything?
Yes, at least in theory that is exactly what should happen.
No idea if that was ever tested with VA-API, but VDPAU and VA-API as
well as OpenCL/OpenGL interop and DRI2/DRI3 buffer sharing should all
use exactly the same code path.
So if I'm not completely mistaken that should work as expected.
>> We should probably add a flag or bit or feature or something like
>> to note that the application explicitly should NOT call
>> before exporting the surface.
> Doesn't this also depend on how the surface is going to be used? What
> happens if I mmap the dma-buf fd and copy from the buffer via CPU? Does
> this also sync implicitly at some point?
In this case the driver doesn't wait for previous activity on a buffer
So before you access anything with the CPU you should indeed call
More information about the mesa-dev