<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Rainer,<br>
<br>
the render thread doesn't wait either.<br>
<br>
See when you dispatch some work the AMD drivers always wait for
prerequisites in the background, not in the foreground.<br>
<br>
The older radeon driver uses hardware semaphores for this while
amdgpu has a GPU scheduler which handles that stuff.<br>
<br>
This is very important because when you hold back rendering work
in the application the driver stack won't know about it and power
management starts to stutter.<br>
<br>
Not so important for 1920p because power management should be able
to compensate the work peaks, but for 4K that's something
mandatory to let the driver be able to estimate future load.<br>
<br>
We even discussed in our multimedia meeting if we shouldn't limit
3D power management when UVD/VCN decoding is active because of
that problem. But I'm not very keen about those workarounds
because it's really counterproductive for transcode use cases to
have the 3D engine idling around with high clocks.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 11.02.2018 um 12:51 schrieb <a class="moz-txt-link-abbreviated" href="mailto:rainer.hochecker@onlinehome.de">rainer.hochecker@onlinehome.de</a>:<br>
</div>
<blockquote type="cite"
cite="mid:trinity-1ac5be21-d65d-45b4-ae88-29a403230469-1518349911333@3c-app-1and1-bs05">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"
<a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a><br>
<b>An:</b> "Philipp Kerling" <a class="moz-txt-link-rfc2396E" href="mailto:pkerling@casix.org"><pkerling@casix.org></a>,
<a class="moz-txt-link-abbreviated" href="mailto:sw@jkqxz.net">sw@jkqxz.net</a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:rainer.hochecker@onlinehome.de">rainer.hochecker@onlinehome.de</a>,
<a class="moz-txt-link-abbreviated" href="mailto:peter.fruehberger@gmail.com">peter.fruehberger@gmail.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:michel@daenzer.net">michel@daenzer.net</a>,
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>, <a class="moz-txt-link-abbreviated" href="mailto:harry.wentland@amd.com">harry.wentland@amd.com</a>,
<a class="moz-txt-link-abbreviated" href="mailto:lrusak@libreelec.tv">lrusak@libreelec.tv</a><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" moz-do-not-send="true">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" moz-do-not-send="true">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>
> <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a
href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev"
target="_blank" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>