Message-ID: <20170110155244.GD31595@intel.com>
Date:   Tue, 10 Jan 2017 17:52:44 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     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

On Tue, Jan 10, 2017 at 05:33:15PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 10, 2017 at 12:26:53PM +0000, Jose Abreu wrote:
> > Hi Ville,
> > 
> > 
> > On 10-01-2017 11:16, Ville Syrjälä wrote:
> > > On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote:
> > >>
> > 
> > [snip]
> > 
> > >> The pixel clock rate is half of the TMDS character rate in 4:2:0
> > >> (in 24 bit), but for example in deep color 48 bit it will be the
> > >> same rate. There is also a reduction to half of htotal, hactive,
> > >> hblank, hfront, hsync and hback but I don't think it's a good
> > >> solution to guide us from there.
> > > I was asking if we can look at a specific modeline and whether we
> > > can tell from that if we would need to output it as 4:2:0.
> > 
> > Hmm, according to HDMI 2.0 spec there are no 4:2:0 only modes and
> > the only way to figure out if the mode is 4:2:0 only (or able) is
> > to parse the VCB and VBD blocks from EDID. The clock is half rate
> > but this is the source that has to figure it out. The mode is
> > still passed in a regular way (By VIC, by timing, ...).
> > 
> > >
> > >> Why does it feel wrong to you
> > >> expanding the uapi?
> > > Because it requires changing every single userspace kms client. And
> > > it's not something userspace should have to worry about.
> > 
> > I agree but, as Daniel said [1], we could make these new HDMI 2.0
> > features optional and only pass them to userspace if client asked
> > for them. What do you think?
> 
> 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.
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.

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.

> 
> > 
> > [1]
> > https://lists.freedesktop.org/archives/dri-devel/2017-January/128683.html
> > 
> > >
> > >> I think its important to say that the chosen colorspace can
> > >> improve performance in systems: for example, as I said, 4:2:0
> > >> 24-bit uses half the rate that RGB 24-bit uses so we have less
> > >> trafic in the bus. I am recently working with a FPGA connected
> > >> trough pcie and I can definitely say that this is true. But, as
> > >> expected, less traffic means less quality in final image so its
> > >> not a matter of letting kernel decide, I think its a matter of
> > >> user choosing between performance vs. quality.
> > > Image quality control for userspace is a much bigger topic. And
> > > something we have no real precedent for at the moment (apart from 
> > > user choosing a different fb pixel format).
> > >
> > > The performance arument is very hardware dependent, and not really
> > > all that relevant IMO. If the user wants the big mode they either
> > > get it or not depending on whether the system can deliver.
> > >
> > 
> > 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.
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Ville Syrjälä
Intel OTC

Powered by blists - more mailing lists