per-plane LUTs and CSCs?

[Alex Deucher]

On Mon, Sep 14, 2020 at 9:32 AM Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>
> On Mon, Sep 14, 2020 at 02:13:09AM -0400, Alex Deucher wrote:
> > On Thu, Sep 10, 2020 at 4:29 AM Simon Ser <contact at emersion.fr> wrote:
> > >
> > > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > >
> > > > On Thu, Sep 10, 2020 at 07:50:59AM +0000, Simon Ser wrote:
> > > >
> > > > > On Wednesday, September 9, 2020 12:57 PM, Laurentiu Palcu laurentiu.palcu at oss.nxp.com wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I was wondering whether you could give me an advise on how to proceed further
> > > > > > with the following issue as I'm preparing to upstream the next set of patches
> > > > > > for the iMX8MQ display controller(DCSS). The display controller has 3 planes,
> > > > > > each with 2 CSCs and one degamma LUT. The CSCs are in front and after the LUT
> > > > > > respectively. Then the output from those 3 pipes is blended together and then
> > > > > > gamma correction is applied using a linear-to-nonlinear LUT and another CSC, if
> > > > > > needed.
> > > > > > Currently, downstream, we have all those CSCs and LUTs hard-coded into a header
> > > > > > file. Based on the colorspace, range, gamut selected for the output and/or
> > > > > > plane input, we pick up the right CSCs and LUTs from that header file to
> > > > > > configure our pipes... I guess this solution does the job, userspace doesn't
> > > > > > need to care much about how to generate those tables. But, it's also not very
> > > > > > flexible in case there is an app smart enough to know and actually generate
> > > > > > their own custom tables. :/
> > > > > > Looking through the dri-devel archives, I've seen that there was a tentative to
> > > > > > implement a more or less generic per-plane LUT/CSC solution but it didn't make
> > > > > > it in due to lack of userspace consumers...
> > > > >
> > > > > Apart from full color management mentioned by Pekka, are there other
> > > > > use-cases for these per-plane props?
> > > > > One thing I can think of is that some drivers annoyingly only apply the
> > > > > per-CRTC gamma LUT to the primary plane. I think it would make more
> > > > > sense to not attach a gamma prop to the CRTC and instead only attach it
> > > > > to the primary plane to make that clear. But I guess that would also
> > > > > break existing user-space?
> > > >
> > > > Uh, which drivers? This would be a driver bug (and there's been plenty of
> > > > those where the cursor has the wrong color temp and fun stuff like that).
> > > > We need to fix these driver issues instead of lamenting in userspace that
> > > > it's all kinda broken :-)
> > >
> > > Apparently this is bug with the old radeon driver [1]. It works fine on
> > > all i915 setups I've tried, and also works fine on amdgpu (with DC).
> > >
> > > I've opened a radeon bug.
> > >
> > > [1]: https://github.com/swaywm/wlroots/issues/968
> >
> > This is a hardware limitation.  I suspend all hardware of a certain
> > age had this same limitation.  Old stuff didn't have multiple planes.
>
> That doesn't sound right to me. mach64 vt/gt and rage128 had an
> overlay plane already. I even vaguely remeber staring at some
> radeon overlay code at some point thinking "that stuff looks
> identical to the rage128 stuff, wonder why it's not shared code?".
>

Ah, yeah, sorry, I forgot about that.  We don't expose that via KMS.
Actually r128 is almost identical to some of the early radeons.  I
actually had a ddx branch years ago which added r128 support to
xf86-video-ati:
https://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support
That overlay plane went away in the r300 time frame IIRC as everyone
moved to using the 3D engine for CSC and scaling.

Alex

> > It had a primary plane and a cursor and gamma didn't apply to the
> > cursor.
>
> That last part I can believe.
>
> --
> Ville Syrjälä
> Intel