Hello all,<br><br>I'm bumping this to layout some progress that has been made on our (Kodi) side and hopefully we can create a road map for what needs to be done on the amd side to get it working with our vaapi implementation.<br><br>I have merged the drm/kms display code into kodi. So in master currently is a simple drm legacy mode. I have an open PR for getting drm atomic working. It currently works on my intel graphics but has issues with other hardware so I haven't merged it yet.<br><br>I have also split out glx code in Kodi so now it is possible to build without vdpau and glx. So if we could get amd working with our vaapi implementation then nvidia would be the only ones using vdpau and glx anymore, the others are on egl.<br><br>Maybe things have changed now that I see the amd DC display code has been queued up for kernel 4.15. Are there any changes in mesa master that may be relevant to our cause?<br><br>What needs to be done?<br> - vasyncsurface??<br> - 10bit support in gbm<br> - vaapi drm egl extensions<br><br>Anything else?<br><br>Thanks,<br>Lukas Rusak <br><div class="gmail_quote"><div dir="ltr">On Sun, Jun 25, 2017 at 2:53 AM Peter Frühberger <<a href="mailto:peter.fruehberger@gmail.com">peter.fruehberger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>just as information: <a href="https://github.com/FernetMenta/kodi-agile/commit/ca8119b4e11a52415125af959f220b280f56ecae" target="_blank">https://github.com/FernetMenta/kodi-agile/commit/ca8119b4e11a52415125af959f220b280f56ecae</a> Rainer moved the specific parts of the buffer sharing into a separate infrastructure see the VAAPIEGL.cpp and VAAPIEGL.h in the above patch.</div><div><br></div><div>This basically encapsulates the fourcc_code('R', '8', ' ', ' '); specific to intel / mesa and makes VAAPI.cpp - the decoder - more generic.</div><div><br></div><div>That means an AMD implementation of above interface can now happen easily by implementing Init / Map / Unmap.</div><div><br></div><div>Have a nice weekend</div></div><div dir="ltr"><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-20 17:00 GMT+01:00 Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Mar 19, 2017 at 2:49 PM, Christian König<br>
<<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a>> wrote:<br>
> Hi Peter,<br>
><br>
> Adding Michel and Marek for the Mesa interop side and Harry for the display<br>
> side.<br>
><br>
> How do you want us to display the decoded surfaces?<br>
><br>
> Well to make a long story short: I don't have the slightest idea. Ideally we<br>
> would of the same handling as Intel so that you guys don't have anything<br>
> vendor dependent in your code.<br>
><br>
> The first step would be to get the VA-API DRM extension to work with EGL. So<br>
> that Kodi is able to export the YUV surfaces and import parts of them as<br>
> 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<br>
> stuff fully supported, e.g. do we also handle the offsets correctly? I've<br>
> added the backend code for this while doing VDPAU interop, but the EGL/GL<br>
> frontend code needs to handle it gracefully as well.<br>
<br>
</span>Mesa/EGL imports an FD with an offset, but it always exports an FD<br>
with offset=0 (the driver offset is ignored). It also always returns<br>
num_planes = 1 on export, is that bad?<br>
<span class="m_939152436180421863HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div class="m_939152436180421863gmail_signature" data-smartmail="gmail_signature"> Key-ID: 0x1A995A9B<br> keyserver: <a 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></div>