Message-ID: <d2d65c73-a257-8dcf-4d85-47bc2dc3d64c@synopsys.com>
Date:   Tue, 10 Jan 2017 17:01:08 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        "Jose Abreu" <Jose.Abreu@...opsys.com>
CC:     <dri-devel@...ts.freedesktop.org>,
        Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville,


[snip]

>> Are you going to update all the userspace clients? Exposing HDMI 2.0
>> modes only for your favorite client doesn't sound like a good plan to
>> me.
>>
>> If we simply compute from a specific modeline whether it needs to be
>> transmitted as 4:2:0, I suppose we could simply look for a matching
>> mode in the 4:2:0 mode. But that would mean that only the exact modes
>> listed by the EDID will work, and others might not.
> OK, so the 4:2:0 support is apparently listed only for specific VICs.

Hmm, the spec is not very clear. It lists video timings which may
be used with YCbCr 4:2:0 but does not explicitly say that only
these timings can be used. Anyway, I checked with a colleague who
has direct access to HDMI Forum and indeed only VIC 96, 97, 101,
102, 106 and 107 can be used with 4:2:0, so you are correct. He
said that the initial intention of this pixel encoding was to
give 60Hz refresh rate in 4k to users who had limited
performance, so it was only intended for higher resolutions.

> Hence we will need to just go through those lists to see if we can
> (or in fact must) use 4:2:0 for a specific user specified mode.

We don't have yet support for these VICs, so this will have to
wait :(

>
> I would say the only slight question mark at this point is whether we
> should favor 4:4:4 at lower bpc or 4:2:0 at higher bpc if we can choose
> between the two. My first instinct is to favor the 4:4:4 modes for now.
> We could add some knobs later to let the user make that choice.

I agree that 4:4:4 should be preferred.

[snip]

>>> Ok. But note that there is no nice way to figure this out. For
>>> example, for a graphics card it all depends (apart from the
>>> graphics HW) on the PCIe bus. If the bus is not free for enough
>>> data rate then user can reach bottlenecks and not output at best
>>> performance. If we gave user the ability to switch from, for
>>> example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated.
>> Userspace won't know anything about such bottlenecks. The kernel
>> can know it and hence should automagically drop into 4:2:0 mode
>> if necessary.
>>
>>> Unless of course we always prefer YCbCr 4:2:0, when possible. I
>>> did this internally for bridge driver dw-hdmi. We always prefer
>>> YCbCr over RGB when they are available. It is user transparent as
>>> the controller does the necessary color space conversion, though,
>>> not ideal in my opinion.
>> My idea was that we'd have a property for the output colorspace and
>> would perhaps default to YCbCr for the CEA modes (as per CEA-861).
>> Though I'm sure some people would cry about that behaviour as well.
>> But for the cases where there is no choice but to use a specific
>> output colorspace, the kernel should just do it automagically IMO. No
>> point in manking life diffcult for userspace.

But we already have color_formats field in drm_display_info
struct, right? Shouldn't we instead create for example a helper
which returns the best output colorspace? According to what you
said it would be something like:

if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
    return YCBCR444;
else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
    return YCBCR422;
else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420
&& vic_is_420)
    return YCBCR420;
else
    return RGB444; /* Mandatory by spec */

>>
>> -- 
>> Ville Syrjälä
>> Intel OTC

Best regards,
Jose Miguel Abreu

Powered by blists - more mailing lists