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

[Lukas Rusak]

Hello all,

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.

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.

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.

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?

What needs to be done?
- vasyncsurface??
- 10bit support in gbm
- vaapi drm egl extensions

Anything else?

Thanks,
Lukas Rusak
On Sun, Jun 25, 2017 at 2:53 AM Peter Frühberger <
peter.fruehberger at gmail.com> wrote:

> Hi all,
>
> just as information:
> https://github.com/FernetMenta/kodi-agile/commit/ca8119b4e11a52415125af959f220b280f56ecae
> Rainer moved the specific parts of the buffer sharing into a separate
> infrastructure see the VAAPIEGL.cpp and VAAPIEGL.h in the above patch.
>
> This basically encapsulates the fourcc_code('R', '8', ' ', ' '); specific
> to intel / mesa and makes VAAPI.cpp - the decoder - more generic.
>
> That means an AMD implementation of above interface can now happen easily
> by implementing Init / Map / Unmap.
>
> Have a nice weekend
> Peter
>
> 2017-03-20 17:00 GMT+01:00 Marek Olšák <maraeo at gmail.com>:
>
>> On Sun, Mar 19, 2017 at 2:49 PM, Christian König
>> <deathsimple at vodafone.de> wrote:
>> > 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.
>>
>> Mesa/EGL imports an FD with an offset, but it always exports an FD
>> with offset=0 (the driver offset is ignored). It also always returns
>> num_planes = 1 on export, is that bad?
>>
>> Marek
>>
>
>
>
> --
>                    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/20170928/5bf5d43a/attachment-0001.html>