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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to