<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<blockquote type="cite">
<div>I suggest to keep it simple from a driver perspective and
require applications to use vaSyncSurface</div>
</blockquote>
Currently our vaSyncSurface doesn't really do what the name
suggests. All what we do is flushing the command buffers and that
for good reasons.<br>
<br>
That the application waits for all decoding to complete before
handing of the surface to the post processing/display engine not
only makes the application trickier to write (fortunately you
already solved that for Kodi), but is also seriously bad for
things like power management.<br>
<br>
In other words we not only do this heavy pipelining of work to
gain throughput, but also for the reason that the kernel driver
and hardware need a good idea of what is coming next. When the
application waits for decoding to finish before handing of post
processing to the we can't make those predictions any more.<br>
<br>
We even discussed to use some sort of hack to signal the kernel
driver during video decode to not drop below a certain power level
to handle such things, but for GL interop that would mean that we
need to set an environment variable for video decoding because we
can't really differentiate the use case from the driver side.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 19.03.2017 um 15:44 schrieb <a class="moz-txt-link-abbreviated" href="mailto:rainer.hochecker@onlinehome.de">rainer.hochecker@onlinehome.de</a>:<br>
</div>
<blockquote
cite="mid:trinity-fb4ad490-bc7f-4c43-ba0e-9f9570119197-1489934682281@3capp-1and1-bs05"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>> for example how does synchronization happen between
the two APIs?</div>
<div> </div>
<div>right, vaapi seems not as matured as vdpau in this regard.
But Kodi's multithreading design does cope with this. We call</div>
<div>vaSyncSurface before feeding vpp and before maping va
buffers to GL.</div>
<div>
<div> </div>
<div>I suggest to keep it simple from a driver perspective and
require applications to use vaSyncSurface</div>
<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,
19. März 2017 um 15:28 Uhr<br>
<b>Von:</b> "Christian König"
<a class="moz-txt-link-rfc2396E" href="mailto:deathsimple@vodafone.de"><deathsimple@vodafone.de></a><br>
<b>An:</b> "Peter Frühberger"
<a class="moz-txt-link-rfc2396E" href="mailto:peter.fruehberger@gmail.com"><peter.fruehberger@gmail.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-rfc2396E" href="mailto:rainer.hochecker@onlinehome.de">"rainer.hochecker@onlinehome.de"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:rainer.hochecker@onlinehome.de"><rainer.hochecker@onlinehome.de></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:lrusak@libreelec.tv">lrusak@libreelec.tv</a>,
"Michel Dänzer" <a class="moz-txt-link-rfc2396E" href="mailto:michel@daenzer.net"><michel@daenzer.net></a>, "Marek Olšák"
<a class="moz-txt-link-rfc2396E" href="mailto:maraeo@gmail.com"><maraeo@gmail.com></a>, "Wentland, Harry"
<a class="moz-txt-link-rfc2396E" href="mailto:Harry.Wentland@amd.com"><Harry.Wentland@amd.com></a><br>
<b>Betreff:</b> Re: 10bit HEVC decoding for RadeonSI v2</div>
<div name="quoted-content">
<div style="background-color: rgb(255,255,255);">
<div class="moz-cite-prefix">
<blockquote>
<div>What do you think?</div>
</blockquote>
In general that it might work, but basic problem is
the API design once more.<br>
<br>
While with VDPAU the steps where applications asks
OpenGL to interop with VDPAU and the two APIs can do
all the handshaking internally.<br>
<br>
With VA-API we have Application exporting buffers from
VA-API and then importing the same buffer as two
surfaces into OpenGL.<br>
<br>
That leaves a whole bunch of open questions, for
example how does synchronization happen between the
two APIs? E.g. the application (Kodi) probably doesn't
wants to wait for the decoding result before it uses
the the surface with OpenGL. We don't have a way to
sync between the two APIs here except for the handle.<br>
<br>
The next problem is how do we communicate the layout
of data in the buffer? E.g. we have the format and the
offset, but that assumes that you don't have any nasty
kind of tilling modes applied here.<br>
<br>
I think we can make that work for now (we aren't using
tilling modes with UVD much anyway), but this is going
to bite us again sooner or later. Going to put the
whole thing on my todo list once more.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 19.03.2017 um 15:06 schrieb Peter Frühberger:</div>
<blockquote>
<div>Hi Christian,
<div> </div>
<div>we use it the following way:</div>
<div>Dependend on the surface NV12 vs. P010 we use:</div>
<div><a moz-do-not-send="true"
href="https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1416"
target="_blank">https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1416</a> </div>
<div> </div>
<div>R8 and GR88</div>
<div> </div>
<div>or alternatively:</div>
<div><a moz-do-not-send="true"
href="https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1493"
target="_blank">https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1493</a></div>
<div> </div>
<div>R16 and GR32</div>
<div> </div>
<div>There is also a possibility to use BGRA, but
this involves internal copy of the yuv surfaces in
vaapi and is therefore not suited well (more
memory and more load).</div>
<div> </div>
<div>For both images Y and UV we
use: eglCreateImageKHR extension follow
by glEGLImageTargetTexture2DOES.</div>
<div> </div>
<div>See: <a moz-do-not-send="true"
href="https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1262"
target="_blank">https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1262</a></div>
<div> </div>
<div>On the VAAPI side:</div>
VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME with
either VA_RT_FORMAT_YUV420 or VA_FOURCC_P010 are
used.
<div> </div>
<div>I think that method is quite generalizable and
nothing is intel specific.</div>
<div> </div>
<div>What do you think?</div>
<div> </div>
<div>Best regards</div>
<div>Peter</div>
<div> </div>
<div> </div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2017-03-19 14:49 GMT+01:00
Christian König <span><<a
moz-do-not-send="true"
href="mailto:deathsimple@vodafone.de"
onclick="parent.window.location.href='deathsimple@vodafone.de';
return false;" target="_blank">deathsimple@vodafone.de</a>></span>:
<blockquote class="gmail_quote" style="margin: 0 0
0 0.8ex;border-left: 1.0px rgb(204,204,204)
solid;padding-left: 1.0ex;">
<div>
<div
class="m_2717980661460678689moz-cite-prefix">Hi
Peter,<br>
<br>
Adding Michel and Marek for the Mesa interop
side and Harry for the display side.<br>
<blockquote><span>How do you want us to
display the decoded surfaces?</span></blockquote>
<span> </span> Well to make a long story
short: I don't have the slightest idea.
Ideally we would of the same handling as
Intel so that you guys don't have anything
vendor dependent in your code.<br>
<br>
The first step would be to get the VA-API
DRM extension to work with EGL. So that Kodi
is able to export the YUV surfaces and
import parts of them as separate R8/R16 or
R8G8/R16G16 surfaces, right?<br>
<br>
What EGL/GL extension do you guys use to
import the surfaces? Marek is that stuff
fully supported, e.g. do we also handle the
offsets correctly? I've added the backend
code for this while doing VDPAU interop, but
the EGL/GL frontend code needs to handle it
gracefully as well.<br>
<br>
The second step is then to teach our DC how
to handle RGB surfaces with 10bit. I doubt
the old code has support for that and we
probably don't want to add it. So Harry can
you comment on how far along we got with
that in DC?<br>
<br>
Regards,<br>
Christian.
<div>
<div class="h5"><br>
<br>
Am 19.03.2017 um 13:26 schrieb Peter
Frühberger:</div>
</div>
</div>
<div>
<div class="h5">
<blockquote>
<div>Hi Christian,
<div> </div>
<div>thank you for your message. We
are still wondering about the render
part. How do you want us to display
the decoded surfaces? Looking at mpv
it seems it will only work via
vaPutSurface and is therefore tight
to X11. That means it's dependend on
the visuals 8 bit only.</div>
<div> </div>
<div>We are working on a drm-only kodi
and now ask ourselves: Is there a
possibility to interop with a drm
extension and eglCreateImage on AMD
hw, too? With the intel only R32, R8
linux buf methods we are also
running succesfully on MIR now,
wayland would work the very same.</div>
<div> </div>
<div>Best regards</div>
<div>Peter</div>
<div> </div>
<div> </div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2017-03-10
17:25 GMT+01:00 <a
moz-do-not-send="true"
href="mailto:rainer.hochecker@onlinehome.de"
onclick="parent.window.location.href='rainer.hochecker@onlinehome.de';
return false;" target="_blank">rainer.hochecker@onlinehome.de</a>
<span><<a moz-do-not-send="true"
href="mailto:rainer.hochecker@onlinehome.de"
onclick="parent.window.location.href='rainer.hochecker@onlinehome.de';
return false;" target="_blank">rainer.hochecker@onlinehome.de</a>></span>:
<blockquote class="gmail_quote"
style="margin: 0 0 0
0.8ex;border-left: 1.0px
rgb(204,204,204)
solid;padding-left: 1.0ex;">
<div>
<div style="font-family:
Verdana;font-size: 12.0px;">
<div>
<div>Hi Christian,</div>
<div> </div>
<div>I already removed the
check for Intel in my dev
branch. On startup</div>
<div>Kodi does a functional
test if vaapi works. If
the test passes, it is
availalbe</div>
<div>regarless of the
underlying type of
hardware/driver.</div>
<div> </div>
<div>Regards,</div>
<div>Rainer</div>
<div>
<div style="margin: 10.0px
5.0px 5.0px
10.0px;padding: 10.0px 0
10.0px
10.0px;border-left:
2.0px solid
rgb(195,217,229);">
<div style="margin: 0 0
10.0px 0;"><b>Gesendet:</b> Mittwoch,
08. März 2017 um 13:29
Uhr<br>
<b>Von:</b> "Christian
König" <<a
moz-do-not-send="true"
href="mailto:deathsimple@vodafone.de"
onclick="parent.window.location.href='deathsimple@vodafone.de';
return false;"
target="_blank">deathsimple@vodafone.de</a>><br>
<b>An:</b> <a
moz-do-not-send="true"
href="mailto:mesa-dev@lists.freedesktop.org"
onclick="parent.window.location.href='mesa-dev@lists.freedesktop.org';
return false;"
target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:rainer.hochecker@onlinehome.de"
onclick="parent.window.location.href='rainer.hochecker@onlinehome.de';
return false;"
target="_blank">rainer.hochecker@onlinehome.de</a>,
<a
moz-do-not-send="true"
href="mailto:peter.fruehberger@gmail.com"
onclick="parent.window.location.href='peter.fruehberger@gmail.com';
return false;"
target="_blank">peter.fruehberger@gmail.com</a><br>
<b>Betreff:</b> 10bit
HEVC decoding for
RadeonSI v2</div>
<div>
<div
class="m_2717980661460678689h5">
<div>Hi guys,<br>
<br>
I finally found
time testing this
and hammering out
(hopefully) all
the<br>
remaining bugs.
Playing a 10bit
HEVC file through
VAAPI with
mpv/ffmpeg git<br>
master from about
two days ago now
works flawlessly
and has only about
15% CPU<br>
load on one core
on a Kaveri
system.<br>
<br>
The VDPAU path
should work as
well, but NVidias
implementation of
this is still<br>
completely broken
and so nobody
enables it and we
don't have a way
to test it.<br>
<br>
Rainer/Peter maybe
you guys want to
take a look and
enable it in Kodi.<br>
<br>
The next logical
step is to get our
display code paths
to be 10bit ready.<br>
<br>
Please review and
comment,<br>
Christian.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div> </div>
--
<div
class="m_2717980661460678689gmail_signature">
Key-ID:
0x1A995A9B<br>
keyserver: <a
moz-do-not-send="true"
href="http://pgp.mit.edu"
target="_blank">pgp.mit.edu</a><br>
==============================================================<br>
Fingerprint: 4606 DA19 EC2E 9A0B
0157 C81B DA07 CF63 1A99 5A9B</div>
</div>
</blockquote>
<p> </p>
</div>
</div>
</div>
</blockquote>
</div>
<div> </div>
--
<div class="gmail_signature">
Key-ID: 0x1A995A9B<br>
keyserver: <a
moz-do-not-send="true" href="http://pgp.mit.edu"
target="_blank">pgp.mit.edu</a><br>
==============================================================<br>
Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07
CF63 1A99 5A9B</div>
</div>
</blockquote>
<p> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>