<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi Christian,</div>
<div> </div>
<div>For Kodi it is better to wait on the thread that does decoding than later </div>
<div>by the render thread. Means it is desired to call it.</div>
<div> </div>
<div>Does vaSyncSurface block as stated by the docs?</div>
<div> </div>
<div>Regards,</div>
<div>Rainer</div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Sonntag, 11. Februar 2018 um 11:02 Uhr<br/>
<b>Von:</b> "Christian König" <christian.koenig@amd.com><br/>
<b>An:</b> "Philipp Kerling" <pkerling@casix.org>, sw@jkqxz.net<br/>
<b>Cc:</b> rainer.hochecker@onlinehome.de, peter.fruehberger@gmail.com, michel@daenzer.net, mesa-dev@lists.freedesktop.org, harry.wentland@amd.com, lrusak@libreelec.tv<br/>
<b>Betreff:</b> Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2</div>
<div name="quoted-content">Am 09.02.2018 um 21:35 schrieb Philipp Kerling:<br/>
> Hi,<br/>
><br/>
> resurrecting this thread again since there's been some progress on the<br/>
> Kodi side.<br/>
><br/>
>> For the EGL part, see <<a href="https://github.com/01org/libva/pull/125" target="_blank">https://github.com/01org/libva/pull/125</a>><br/>
>> and <<a href="https://lists.freedesktop.org/archives/mesa-dev/2017-October/171246.html" target="_blank">https://lists.freedesktop.org/archives/mesa-dev/2017-October/171246.html</a>>.<br/>
> We recently started testing vaExportSurfaceHandle support, so we will<br/>
> have this covered soon.<br/>
><br/>
>> I have been testing with mpv and ffmpeg; any thoughts from the<br/>
>> Kodi point of view would be most welcome.<br/>
> It generally works quite well, but we still have the unresolved<br/>
> vaSyncSurface problem.<br/>
> To recap: vaExportSurfaceHandle requires calling vaSyncSurface to make<br/>
> sure that the decode is actually finished and the buffer is usable<br/>
> before rendering the frame. However, vaSyncSurface was largely<br/>
> unimplemented on mesa back then and it was unclear how to proceed with<br/>
> regard to decode (VAAPI)/present (EGL+GL) synchronization.<br/>
><br/>
> So on to the question: Is this still the case, or has there been<br/>
> progress on implementing vaSyncSurface in mesa? In either case, do we<br/>
> need that support or does this syncing work implicitly somehow on AMD?<br/>
><br/>
> I've noticed that mpv does not seem to call vaSyncSurface, although it<br/>
> technically should.<br/>
<br/>
Actually the mpv approach is correct.<br/>
<br/>
Calling vaSyncSurface is unnecessary and undesired for AMD hardware<br/>
because it moves synchronization to the CPU while it should happen on<br/>
the GPU and/or GPU scheduler.<br/>
<br/>
E.g. our 3D pipeline can wait for hardware video decoding to finish<br/>
before starting the rendering. We even have some implementations which<br/>
allow the 3D pipeline to start when only the first halve of the picture<br/>
is decoded etc..<br/>
<br/>
If we don't do this the 3D pipeline runs dry between frame decoding<br/>
which leads to problems with power management.<br/>
<br/>
We should probably add a flag or bit or feature or something like this<br/>
to note that the application explicitly should NOT call vaSyncSurface<br/>
before exporting the surface.<br/>
<br/>
Regards,<br/>
Christian.<br/>
<br/>
><br/>
> Best regards,<br/>
> Philipp<br/>
> _______________________________________________<br/>
> mesa-dev mailing list<br/>
> mesa-dev@lists.freedesktop.org<br/>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br/>
</div>
</div>
</div></div></body></html>