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

[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?

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

Regards,
Philipp