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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
