[Mesa-dev] 10bit HEVC decoding for RadeonSI v2

[Christian König]

Am 11.02.2018 um 11:35 schrieb Philipp Kerling:
> Hi,
>
> 2018-02-11 (日) の 11:02 +0100 に Christian König さんは書きました:
>> Am 09.02.2018 um 21:35 schrieb Philipp Kerling:
>>> Hi,
>>>
>>> resurrecting this thread again since there's been some progress on
>>> the
>>> Kodi side.
>>>
>>>> For the EGL part, see <https://github.com/01org/libva/pull/125>
>>>> and <https://lists.freedesktop.org/archives/mesa-dev/2017-October
>>>> /171246.html>.
>>> We recently started testing vaExportSurfaceHandle support, so we
>>> will
>>> 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
>>> make
>>> 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
>>> with
>>> 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
>>> we
>>> need that support or does this syncing work implicitly somehow on
>>> AMD?
>>>
>>> I've noticed that mpv does not seem to call vaSyncSurface, although
>>> it
>>> 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
>> on
>> 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
>> which
>> allow the 3D pipeline to start when only the first halve of the
>> picture
>> 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
>> this
>> to note that the application explicitly should NOT call
>> vaSyncSurface
>> 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 
to end.

So before you access anything with the CPU you should indeed call 
vaSyncSurface.

Christian.

>
> Regards,
> Philipp