[Mesa-dev] 10bit HEVC decoding for RadeonSI v2

[Peter Frühberger]

Hi Christian,

we use it the following way:
Dependend on the surface NV12 vs. P010 we use:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1416


R8 and GR88

or alternatively:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1493

R16 and GR32

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).

For both images Y and UV we use: eglCreateImageKHR extension follow
by glEGLImageTargetTexture2DOES.

See:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1262

On the VAAPI side:
VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME with either VA_RT_FORMAT_YUV420
or VA_FOURCC_P010 are used.

I think that method is quite generalizable and nothing is intel specific.

What do you think?

Best regards
Peter



2017-03-19 14:49 GMT+01:00 Christian König <deathsimple at vodafone.de>:

> Hi Peter,
>
> Adding Michel and Marek for the Mesa interop side and Harry for the
> display side.
>
> How do you want us to display the decoded surfaces?
>
> 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.
>
> 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?
>
> 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.
>
> 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?
>
> Regards,
> Christian.
>
>
> Am 19.03.2017 um 13:26 schrieb Peter Frühberger:
>
> Hi Christian,
>
> 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.
>
> 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.
>
> Best regards
> Peter
>
>
>
> 2017-03-10 17:25 GMT+01:00 rainer.hochecker at onlinehome.de <
> rainer.hochecker at onlinehome.de>:
>
>> Hi Christian,
>>
>> I already removed the check for Intel in my dev branch. On startup
>> Kodi does a functional test if vaapi works. If the test passes, it is
>> availalbe
>> regarless of the underlying type of hardware/driver.
>>
>> Regards,
>> Rainer
>>
>> *Gesendet:* Mittwoch, 08. März 2017 um 13:29 Uhr
>> *Von:* "Christian König" <deathsimple at vodafone.de>
>> *An:* mesa-dev at lists.freedesktop.org
>> *Cc:* rainer.hochecker at onlinehome.de, peter.fruehberger at gmail.com
>> *Betreff:* 10bit HEVC decoding for RadeonSI v2
>> Hi guys,
>>
>> I finally found time testing this and hammering out (hopefully) all the
>> remaining bugs. Playing a 10bit HEVC file through VAAPI with mpv/ffmpeg
>> git
>> master from about two days ago now works flawlessly and has only about
>> 15% CPU
>> load on one core on a Kaveri system.
>>
>> The VDPAU path should work as well, but NVidias implementation of this is
>> still
>> completely broken and so nobody enables it and we don't have a way to
>> test it.
>>
>> Rainer/Peter maybe you guys want to take a look and enable it in Kodi.
>>
>> The next logical step is to get our display code paths to be 10bit ready.
>>
>> Please review and comment,
>> Christian.
>>
>>
>
>
>
> --
>                    Key-ID:     0x1A995A9B
>                    keyserver: pgp.mit.edu
> ==============================================================
> Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
>
>
>


-- 
                   Key-ID:     0x1A995A9B
                   keyserver: pgp.mit.edu
==============================================================
Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170319/d8c5ba2b/attachment-0001.html>