per-plane LUTs and CSCs?

per-plane LUTs and CSCs?

[Laurentiu Palcu]

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

Adding CSC and degamma LUT properties for each plane as well as a gamma
LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
entirely on userspace to fill in those tables. But userspace has to know
how to generate those LUTs and colorspace conversion matrices in the
first place...

So, how should I continue with this one? Any pointers?

Thanks,
Laurentiu
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 2129 bytes --]

On Wed, 9 Sep 2020 13:57:28 +0300
Laurentiu Palcu <laurentiu.palcu@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...
> 
> Adding CSC and degamma LUT properties for each plane as well as a gamma
> LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> entirely on userspace to fill in those tables. But userspace has to know
> how to generate those LUTs and colorspace conversion matrices in the
> first place...
> 
> So, how should I continue with this one? Any pointers?

Hi,

I can't help you, but I can say that we are currently in the process of
designing a color management and HDR extension for Wayland, and I'm
sure in the long term I would like to use per-plane color space
transformation features of KMS in Weston eventually.

IOW, one more userspace that is going to be taking advantage of such
features as long as they are not too driver-specific.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Simon Ser]

On Wednesday, September 9, 2020 12:57 PM, Laurentiu Palcu <laurentiu.palcu@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?

The gamma LUT is currently used by some compositors to implement "night
light"/redshift-like features.

> Adding CSC and degamma LUT properties for each plane as well as a gamma
> LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> entirely on userspace to fill in those tables. But userspace has to know
> how to generate those LUTs and colorspace conversion matrices in the
> first place...

So it wouldn't be enough for user-space to fill these gamma LUTs with
linear ramps and get colors that look fine? Would the process be more
involved? Would user-space need to know about the driver and generate
gamma LUTs depending on the driver?

That would be a show-stopper.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Daniel Vetter]

On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> On Wed, 9 Sep 2020 13:57:28 +0300
> Laurentiu Palcu <laurentiu.palcu@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...
> > 
> > Adding CSC and degamma LUT properties for each plane as well as a gamma
> > LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> > entirely on userspace to fill in those tables. But userspace has to know
> > how to generate those LUTs and colorspace conversion matrices in the
> > first place...

I think even if we have userspace doing this, we still need the default
tables so that old userspace keeps working. E.g. I'm assuming this is also
used for yuv->rgb conversion and range limiting and all these things. In
i915 I think we even combine the userspace lut/csc with the one we need
for color space fixes in some cases.

So maybe a helper library which helps drivers do that would also be
needed.

> > So, how should I continue with this one? Any pointers?
> 
> Hi,
> 
> I can't help you, but I can say that we are currently in the process of
> designing a color management and HDR extension for Wayland, and I'm
> sure in the long term I would like to use per-plane color space
> transformation features of KMS in Weston eventually.
> 
> IOW, one more userspace that is going to be taking advantage of such
> features as long as they are not too driver-specific.

Personally I think best to wait for userspace to come up with color
manager protocols, that should give us a much clearer idea of what the
kernel interface should look like. Since hw is pretty special in this
area, I expect we'll have to do a bunch of impendendance mismatching in
the kernel anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Daniel Vetter]

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@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 :-)
-Daniel

> 
> The gamma LUT is currently used by some compositors to implement "night
> light"/redshift-like features.
> 
> > Adding CSC and degamma LUT properties for each plane as well as a gamma
> > LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> > entirely on userspace to fill in those tables. But userspace has to know
> > how to generate those LUTs and colorspace conversion matrices in the
> > first place...
> 
> So it wouldn't be enough for user-space to fill these gamma LUTs with
> linear ramps and get colors that look fine? Would the process be more
> involved? Would user-space need to know about the driver and generate
> gamma LUTs depending on the driver?
> 
> That would be a show-stopper.

Yeah we can't expose such an uapi, instead what I have in mind that the
in-kernel lut/csc for yuv/broadcast rgb and whatever else are mixed in
with what userspace provides. That means a slight loss of precision and
we'll have to have a nice fixed point math library for this stuff in the
kernel. But color correction hw is too special between vendors that I
don't think there's any other solution. E.g. even on intel we sometimes
have dedicated register bits/hw functions for yuv/rgb broadcast value
range and whatever else, and on other platforms we need to do that by
adjusting the lut/csc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Simon Ser]

On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel@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@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

> > The gamma LUT is currently used by some compositors to implement "night
> > light"/redshift-like features.
> >
> > > Adding CSC and degamma LUT properties for each plane as well as a gamma
> > > LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> > > entirely on userspace to fill in those tables. But userspace has to know
> > > how to generate those LUTs and colorspace conversion matrices in the
> > > first place...
> >
> > So it wouldn't be enough for user-space to fill these gamma LUTs with
> > linear ramps and get colors that look fine? Would the process be more
> > involved? Would user-space need to know about the driver and generate
> > gamma LUTs depending on the driver?
> > That would be a show-stopper.
>
> Yeah we can't expose such an uapi, instead what I have in mind that the
> in-kernel lut/csc for yuv/broadcast rgb and whatever else are mixed in
> with what userspace provides. That means a slight loss of precision and
> we'll have to have a nice fixed point math library for this stuff in the
> kernel. But color correction hw is too special between vendors that I
> don't think there's any other solution. E.g. even on intel we sometimes
> have dedicated register bits/hw functions for yuv/rgb broadcast value
> range and whatever else, and on other platforms we need to do that by
> adjusting the lut/csc.

Yeah, that makes sense to me.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 3359 bytes --]

On Thu, 10 Sep 2020 09:52:26 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> > On Wed, 9 Sep 2020 13:57:28 +0300
> > Laurentiu Palcu <laurentiu.palcu@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.

Hi,

hmm, so FB -> CSC -> LUT -> CSC -> blending?

Is it then
	blending -> LUT -> CSC -> encoder
or
	blending -> CSC -> LUT -> encoder?

Are all these LUTs per-channel 1D LUTs or something else?

What ever the KMS UAPI for these is going to be looking like, it
obviously needs to define all this. So I'm guessing we need to define
the abstract color pipeline of KMS in general that includes everything
any driver might want to expose. Then each driver picks the blocks in
the pipeline it wants to expose and the other blocks are assumed to be
"identity transform".

Without such general abstract color pipeline defined and documented it
is very unlikely IMO for generic userspace to make use of the driver
features.

All blocks must also default to identity transform. A block
unimplemented by a driver is the same as a block not used or understood
by a KMS client.

Userspace that does not understand all the blocks will need to use the
"harmless default values". This then ties in with what I've discussed
with danvet before: when you are VT-switching from one KMS client to
another, how do you reset the full KMS state (including blocks you
don't understand) to the same state you had before. The other KMS
client may have messed them up while you were gone.

All this default value talk is to ensure that the abstract KMS color
pipeline can be extended without breaking existing userspace.

...

> > > So, how should I continue with this one? Any pointers?  
> > 
> > Hi,
> > 
> > I can't help you, but I can say that we are currently in the process of
> > designing a color management and HDR extension for Wayland, and I'm
> > sure in the long term I would like to use per-plane color space
> > transformation features of KMS in Weston eventually.
> > 
> > IOW, one more userspace that is going to be taking advantage of such
> > features as long as they are not too driver-specific.  
> 
> Personally I think best to wait for userspace to come up with color
> manager protocols, that should give us a much clearer idea of what the
> kernel interface should look like. Since hw is pretty special in this
> area, I expect we'll have to do a bunch of impendendance mismatching in
> the kernel anyway.

Speaking of that, where should we scream if we feel like we are missing
KMS properties to get the best out of color management and HDR in
Weston, assuming we're not kernel devs?

Who to Cc?

We currently have intel and AMD hardware at hand if that makes any
difference.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Laurentiu Palcu]

Hi Pekka,

On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 09:52:26 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> > > On Wed, 9 Sep 2020 13:57:28 +0300
> > > Laurentiu Palcu <laurentiu.palcu@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.
> 
> Hi,
> 
> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> 
> Is it then
> 	blending -> LUT -> CSC -> encoder
> or
> 	blending -> CSC -> LUT -> encoder?

The DCSS pipeline topology is this:

FB1->CSC_A->LUT->CSC_B-\
FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
FB3->CSC_A->LUT->CSC_B-/

Basically, CSC_A is used to convert to a common colorspace if needed
(YUV->RGB) as well as to perform pixel range conversions: limited->full.
CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
convert to the colorspace used by the output (like RGB->YUV).

> 
> Are all these LUTs per-channel 1D LUTs or something else?

LUTs are 3D, per pixel component.

Thanks,
laurentiu

> 
> What ever the KMS UAPI for these is going to be looking like, it
> obviously needs to define all this. So I'm guessing we need to define
> the abstract color pipeline of KMS in general that includes everything
> any driver might want to expose. Then each driver picks the blocks in
> the pipeline it wants to expose and the other blocks are assumed to be
> "identity transform".
> 
> Without such general abstract color pipeline defined and documented it
> is very unlikely IMO for generic userspace to make use of the driver
> features.
> 
> All blocks must also default to identity transform. A block
> unimplemented by a driver is the same as a block not used or understood
> by a KMS client.
> 
> Userspace that does not understand all the blocks will need to use the
> "harmless default values". This then ties in with what I've discussed
> with danvet before: when you are VT-switching from one KMS client to
> another, how do you reset the full KMS state (including blocks you
> don't understand) to the same state you had before. The other KMS
> client may have messed them up while you were gone.
> 
> All this default value talk is to ensure that the abstract KMS color
> pipeline can be extended without breaking existing userspace.
> 
> ...
> 
> > > > So, how should I continue with this one? Any pointers?  
> > > 
> > > Hi,
> > > 
> > > I can't help you, but I can say that we are currently in the process of
> > > designing a color management and HDR extension for Wayland, and I'm
> > > sure in the long term I would like to use per-plane color space
> > > transformation features of KMS in Weston eventually.
> > > 
> > > IOW, one more userspace that is going to be taking advantage of such
> > > features as long as they are not too driver-specific.  
> > 
> > Personally I think best to wait for userspace to come up with color
> > manager protocols, that should give us a much clearer idea of what the
> > kernel interface should look like. Since hw is pretty special in this
> > area, I expect we'll have to do a bunch of impendendance mismatching in
> > the kernel anyway.
> 
> Speaking of that, where should we scream if we feel like we are missing
> KMS properties to get the best out of color management and HDR in
> Weston, assuming we're not kernel devs?
> 
> Who to Cc?
> 
> We currently have intel and AMD hardware at hand if that makes any
> difference.
> 
> 
> Thanks,
> pq


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 2441 bytes --]

On Thu, 10 Sep 2020 12:30:09 +0300
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> wrote:

> Hi Pekka,
> 
> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> > On Thu, 10 Sep 2020 09:52:26 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >   
> > > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:  
> > > > On Wed, 9 Sep 2020 13:57:28 +0300
> > > > Laurentiu Palcu <laurentiu.palcu@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.  
> > 
> > Hi,
> > 
> > hmm, so FB -> CSC -> LUT -> CSC -> blending?
> > 
> > Is it then
> > 	blending -> LUT -> CSC -> encoder
> > or
> > 	blending -> CSC -> LUT -> encoder?  
> 
> The DCSS pipeline topology is this:
> 
> FB1->CSC_A->LUT->CSC_B-\
> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> FB3->CSC_A->LUT->CSC_B-/
> 
> Basically, CSC_A is used to convert to a common colorspace if needed
> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> convert to the colorspace used by the output (like RGB->YUV).

I didn't realize that it would be correct to do RGB-YUV conversion in
non-linear space, but yeah, that's what most software do too I guess.

> > 
> > Are all these LUTs per-channel 1D LUTs or something else?  
> 
> LUTs are 3D, per pixel component.

Sorry, which one?

An example of a 3D LUT is 32x32x32 entries with each entry being a
triplet, while a 1D LUT could be 1024 entries with each entry being a
scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
you need just one for the color value triplet mapping.

A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
channel mixing that a CTM can.

So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
blocks exist...


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Laurentiu Palcu]

Hi Pekka,

On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 12:30:09 +0300
> Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> wrote:
> 
> > Hi Pekka,
> > 
> > On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> > > On Thu, 10 Sep 2020 09:52:26 +0200
> > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > >   
> > > > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:  
> > > > > On Wed, 9 Sep 2020 13:57:28 +0300
> > > > > Laurentiu Palcu <laurentiu.palcu@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.  
> > > 
> > > Hi,
> > > 
> > > hmm, so FB -> CSC -> LUT -> CSC -> blending?
> > > 
> > > Is it then
> > > 	blending -> LUT -> CSC -> encoder
> > > or
> > > 	blending -> CSC -> LUT -> encoder?  
> > 
> > The DCSS pipeline topology is this:
> > 
> > FB1->CSC_A->LUT->CSC_B-\
> > FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> > FB3->CSC_A->LUT->CSC_B-/
> > 
> > Basically, CSC_A is used to convert to a common colorspace if needed
> > (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> > CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> > convert to the colorspace used by the output (like RGB->YUV).
> 
> I didn't realize that it would be correct to do RGB-YUV conversion in
> non-linear space, but yeah, that's what most software do too I guess.
> 
> > > 
> > > Are all these LUTs per-channel 1D LUTs or something else?  
> > 
> > LUTs are 3D, per pixel component.
> 
> Sorry, which one?
> 
> An example of a 3D LUT is 32x32x32 entries with each entry being a
> triplet, while a 1D LUT could be 1024 entries with each entry being a
> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> you need just one for the color value triplet mapping.
> 
> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> channel mixing that a CTM can.
> 
> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> blocks exist...

Indeed, it's 1D LUTs. I got them mixed up... :/ Sorry about that.

Thanks,
Laurentiu

> 
> 
> Thanks,
> pq


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Laurent Pinchart]

Hi Pekka,

On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> 
> > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> > > On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.
> 
> Hi,
> 
> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> 
> Is it then
> 	blending -> LUT -> CSC -> encoder
> or
> 	blending -> CSC -> LUT -> encoder?
> 
> Are all these LUTs per-channel 1D LUTs or something else?

If we want to define the color pipeline, we need to also take into
account 3D LUTs that use the full R,G,B value as an index in a 3D table.
In practice the table is decimated of course, otherwise it would take
too much space. The R-Car DU supports this feature in the output path:

	blending -> CSC -> 3D-LUT -> LUT -> encoder

> What ever the KMS UAPI for these is going to be looking like, it
> obviously needs to define all this. So I'm guessing we need to define
> the abstract color pipeline of KMS in general that includes everything
> any driver might want to expose. Then each driver picks the blocks in
> the pipeline it wants to expose and the other blocks are assumed to be
> "identity transform".
> 
> Without such general abstract color pipeline defined and documented it
> is very unlikely IMO for generic userspace to make use of the driver
> features.
> 
> All blocks must also default to identity transform. A block
> unimplemented by a driver is the same as a block not used or understood
> by a KMS client.
> 
> Userspace that does not understand all the blocks will need to use the
> "harmless default values". This then ties in with what I've discussed
> with danvet before: when you are VT-switching from one KMS client to
> another, how do you reset the full KMS state (including blocks you
> don't understand) to the same state you had before. The other KMS
> client may have messed them up while you were gone.
> 
> All this default value talk is to ensure that the abstract KMS color
> pipeline can be extended without breaking existing userspace.
> 
> ...
> 
> > > > So, how should I continue with this one? Any pointers?  
> > > 
> > > Hi,
> > > 
> > > I can't help you, but I can say that we are currently in the process of
> > > designing a color management and HDR extension for Wayland, and I'm
> > > sure in the long term I would like to use per-plane color space
> > > transformation features of KMS in Weston eventually.
> > > 
> > > IOW, one more userspace that is going to be taking advantage of such
> > > features as long as they are not too driver-specific.  
> > 
> > Personally I think best to wait for userspace to come up with color
> > manager protocols, that should give us a much clearer idea of what the
> > kernel interface should look like. Since hw is pretty special in this
> > area, I expect we'll have to do a bunch of impendendance mismatching in
> > the kernel anyway.
> 
> Speaking of that, where should we scream if we feel like we are missing
> KMS properties to get the best out of color management and HDR in
> Weston, assuming we're not kernel devs?
> 
> Who to Cc?

You can CC me for Renesas. I'm not necessarily the most knowledgeable
person on this topic, but I can at least dispatch to developers who
could help.

> We currently have intel and AMD hardware at hand if that makes any
> difference.

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Laurent Pinchart]

Hi Pekka,

On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
> > On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> > > On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> > > > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:  
> > > > > On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.  
> > > 
> > > Hi,
> > > 
> > > hmm, so FB -> CSC -> LUT -> CSC -> blending?
> > > 
> > > Is it then
> > > 	blending -> LUT -> CSC -> encoder
> > > or
> > > 	blending -> CSC -> LUT -> encoder?  
> > 
> > The DCSS pipeline topology is this:
> > 
> > FB1->CSC_A->LUT->CSC_B-\
> > FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> > FB3->CSC_A->LUT->CSC_B-/
> > 
> > Basically, CSC_A is used to convert to a common colorspace if needed
> > (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> > CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> > convert to the colorspace used by the output (like RGB->YUV).
> 
> I didn't realize that it would be correct to do RGB-YUV conversion in
> non-linear space, but yeah, that's what most software do too I guess.
> 
> > > 
> > > Are all these LUTs per-channel 1D LUTs or something else?  
> > 
> > LUTs are 3D, per pixel component.
> 
> Sorry, which one?
> 
> An example of a 3D LUT is 32x32x32 entries with each entry being a
> triplet, while a 1D LUT could be 1024 entries with each entry being a
> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> you need just one for the color value triplet mapping.
> 
> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> channel mixing that a CTM can.
> 
> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> blocks exist...

Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
R-Car), having a separate CSC can give more precision (as well as
allowing the two problems to be decoupled, at a relatively low hardware
cost).

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Ville Syrjälä]

On Thu, Sep 10, 2020 at 10:18:36AM +0200, Daniel Vetter 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@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 :-)

Quite a bit of old hardware simpy couldn't apply the gamma to the
other planes. But hopefully that is no longer the case for any
modern hardware.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Vitaly Prosyak]

[-- Attachment #1.1: Type: text/plain, Size: 2755 bytes --]


On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
> Hi Pekka,
>
> On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
>> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
>>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
>>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
>>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
>>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.
>>>> Hi,
>>>>
>>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
>>>>
>>>> Is it then
>>>> 	blending -> LUT -> CSC -> encoder
>>>> or
>>>> 	blending -> CSC -> LUT -> encoder?
>>> The DCSS pipeline topology is this:
>>>
>>> FB1->CSC_A->LUT->CSC_B-\
>>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
>>> FB3->CSC_A->LUT->CSC_B-/
>>>
>>> Basically, CSC_A is used to convert to a common colorspace if needed
>>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
>>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
>>> convert to the colorspace used by the output (like RGB->YUV).
>> I didn't realize that it would be correct to do RGB-YUV conversion in
>> non-linear space, but yeah, that's what most software do too I guess.
>>
>>>> Are all these LUTs per-channel 1D LUTs or something else?
>>> LUTs are 3D, per pixel component.
>> Sorry, which one?
>>
>> An example of a 3D LUT is 32x32x32 entries with each entry being a
>> triplet, while a 1D LUT could be 1024 entries with each entry being a
>> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
>> you need just one for the color value triplet mapping.
>>
>> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
>> channel mixing that a CTM can.
>>
>> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
>> blocks exist...
> Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
> R-Car), having a separate CSC can give more precision (as well as
> allowing the two problems to be decoupled, at a relatively low hardware
> cost).

If you put nonlinear signal to 3DLUT then your
precision would be improved.
How many bits each color value has in 3DLUT ?



[-- Attachment #1.2: Type: text/html, Size: 4339 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Laurent Pinchart]

Hi Vitaly,

On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:
> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
> > On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
> >> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
> >>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> >>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> >>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> >>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.
> >>>>
> >>>> Hi,
> >>>>
> >>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> >>>>
> >>>> Is it then
> >>>> 	blending -> LUT -> CSC -> encoder
> >>>> or
> >>>> 	blending -> CSC -> LUT -> encoder?
> >>>
> >>> The DCSS pipeline topology is this:
> >>>
> >>> FB1->CSC_A->LUT->CSC_B-\
> >>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> >>> FB3->CSC_A->LUT->CSC_B-/
> >>>
> >>> Basically, CSC_A is used to convert to a common colorspace if needed
> >>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> >>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> >>> convert to the colorspace used by the output (like RGB->YUV).
> >>
> >> I didn't realize that it would be correct to do RGB-YUV conversion in
> >> non-linear space, but yeah, that's what most software do too I guess.
> >>
> >>>> Are all these LUTs per-channel 1D LUTs or something else?
> >>>
> >>> LUTs are 3D, per pixel component.
> >>
> >> Sorry, which one?
> >>
> >> An example of a 3D LUT is 32x32x32 entries with each entry being a
> >> triplet, while a 1D LUT could be 1024 entries with each entry being a
> >> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> >> you need just one for the color value triplet mapping.
> >>
> >> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> >> channel mixing that a CTM can.
> >>
> >> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> >> blocks exist...
> >
> > Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
> > R-Car), having a separate CSC can give more precision (as well as
> > allowing the two problems to be decoupled, at a relatively low hardware
> > cost).
> 
> If you put nonlinear signal to 3DLUT then your
> precision would be improved.
> How many bits each color value has in 3DLUT ?

The whole display pipeline uses 8 bits per component.

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Vitaly Prosyak]

[-- Attachment #1.1: Type: text/plain, Size: 3227 bytes --]


On 2020-09-10 1:51 p.m., Laurent Pinchart wrote:
> Hi Vitaly,
>
> On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:
>> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
>>> On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
>>>> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
>>>>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
>>>>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
>>>>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
>>>>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.
>>>>>> Hi,
>>>>>>
>>>>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
>>>>>>
>>>>>> Is it then
>>>>>> 	blending -> LUT -> CSC -> encoder
>>>>>> or
>>>>>> 	blending -> CSC -> LUT -> encoder?
>>>>> The DCSS pipeline topology is this:
>>>>>
>>>>> FB1->CSC_A->LUT->CSC_B-\
>>>>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
>>>>> FB3->CSC_A->LUT->CSC_B-/
>>>>>
>>>>> Basically, CSC_A is used to convert to a common colorspace if needed
>>>>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
>>>>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
>>>>> convert to the colorspace used by the output (like RGB->YUV).
>>>> I didn't realize that it would be correct to do RGB-YUV conversion in
>>>> non-linear space, but yeah, that's what most software do too I guess.
>>>>
>>>>>> Are all these LUTs per-channel 1D LUTs or something else?
>>>>> LUTs are 3D, per pixel component.
>>>> Sorry, which one?
>>>>
>>>> An example of a 3D LUT is 32x32x32 entries with each entry being a
>>>> triplet, while a 1D LUT could be 1024 entries with each entry being a
>>>> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
>>>> you need just one for the color value triplet mapping.
>>>>
>>>> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
>>>> channel mixing that a CTM can.
>>>>
>>>> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
>>>> blocks exist...
>>> Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
>>> R-Car), having a separate CSC can give more precision (as well as
>>> allowing the two problems to be decoupled, at a relatively low hardware
>>> cost).
>> If you put nonlinear signal to 3DLUT then your
>> precision would be improved.
>> How many bits each color value has in 3DLUT ?
> The whole display pipeline uses 8 bits per component.

It is pretty low , please, use always nonlinear signal in the pipe and it allows you to compress and 'win' about 2 bits.

-- 
[AMD Official Use Only - Internal Distribution Only]

[-- Attachment #1.2: Type: text/html, Size: 5099 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Vitaly Prosyak]

[-- Attachment #1.1: Type: text/plain, Size: 3510 bytes --]


On 2020-09-10 2:07 p.m., Vitaly Prosyak wrote:
>
>
> On 2020-09-10 1:51 p.m., Laurent Pinchart wrote:
>> Hi Vitaly,
>>
>> On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:
>>> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
>>>> On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
>>>>> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
>>>>>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
>>>>>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
>>>>>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
>>>>>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.
>>>>>>> Hi,
>>>>>>>
>>>>>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
>>>>>>>
>>>>>>> Is it then
>>>>>>> 	blending -> LUT -> CSC -> encoder
>>>>>>> or
>>>>>>> 	blending -> CSC -> LUT -> encoder?
>>>>>> The DCSS pipeline topology is this:
>>>>>>
>>>>>> FB1->CSC_A->LUT->CSC_B-\
>>>>>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
>>>>>> FB3->CSC_A->LUT->CSC_B-/
>>>>>>
>>>>>> Basically, CSC_A is used to convert to a common colorspace if needed
>>>>>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
>>>>>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
>>>>>> convert to the colorspace used by the output (like RGB->YUV).
>>>>> I didn't realize that it would be correct to do RGB-YUV conversion in
>>>>> non-linear space, but yeah, that's what most software do too I guess.
>>>>>
>>>>>>> Are all these LUTs per-channel 1D LUTs or something else?
>>>>>> LUTs are 3D, per pixel component.
>>>>> Sorry, which one?
>>>>>
>>>>> An example of a 3D LUT is 32x32x32 entries with each entry being a
>>>>> triplet, while a 1D LUT could be 1024 entries with each entry being a
>>>>> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
>>>>> you need just one for the color value triplet mapping.
>>>>>
>>>>> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
>>>>> channel mixing that a CTM can.
>>>>>
>>>>> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
>>>>> blocks exist...
>>>> Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
>>>> R-Car), having a separate CSC can give more precision (as well as
>>>> allowing the two problems to be decoupled, at a relatively low hardware
>>>> cost).
>>> If you put nonlinear signal to 3DLUT then your
>>> precision would be improved.
>>> How many bits each color value has in 3DLUT ?
>> The whole display pipeline uses 8 bits per component.
> It is pretty low , please, use always nonlinear signal in the pipe and it allows you to compress and 'win' about 2 bits.

Do you have alpha and de-alpha blocks in your pipeline?
You can do CSC and blending in nonlinear mode, it is less accurate than in linear, but it is viable way.
Also alpha should be removed (if it is applied) before CSC.



[-- Attachment #1.2: Type: text/html, Size: 5401 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 4221 bytes --]

On Thu, 10 Sep 2020 15:39:07 -0400
Vitaly Prosyak <vitaly.prosyak@amd.com> wrote:

> On 2020-09-10 2:07 p.m., Vitaly Prosyak wrote:
> >
> >
> > On 2020-09-10 1:51 p.m., Laurent Pinchart wrote:  
> >> Hi Vitaly,
> >>
> >> On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:  
> >>> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:  
> >>>> On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:  
> >>>>> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:  
> >>>>>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:  
> >>>>>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:  
> >>>>>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:  
> >>>>>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu 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.  
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> >>>>>>>
> >>>>>>> Is it then
> >>>>>>> 	blending -> LUT -> CSC -> encoder
> >>>>>>> or
> >>>>>>> 	blending -> CSC -> LUT -> encoder?  
> >>>>>> The DCSS pipeline topology is this:
> >>>>>>
> >>>>>> FB1->CSC_A->LUT->CSC_B-\
> >>>>>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> >>>>>> FB3->CSC_A->LUT->CSC_B-/
> >>>>>>
> >>>>>> Basically, CSC_A is used to convert to a common colorspace if needed
> >>>>>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> >>>>>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> >>>>>> convert to the colorspace used by the output (like RGB->YUV).  
> >>>>> I didn't realize that it would be correct to do RGB-YUV conversion in
> >>>>> non-linear space, but yeah, that's what most software do too I guess.
> >>>>>  
> >>>>>>> Are all these LUTs per-channel 1D LUTs or something else?  
> >>>>>> LUTs are 3D, per pixel component.  
> >>>>> Sorry, which one?
> >>>>>
> >>>>> An example of a 3D LUT is 32x32x32 entries with each entry being a
> >>>>> triplet, while a 1D LUT could be 1024 entries with each entry being a
> >>>>> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> >>>>> you need just one for the color value triplet mapping.
> >>>>>
> >>>>> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> >>>>> channel mixing that a CTM can.
> >>>>>
> >>>>> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> >>>>> blocks exist...  
> >>>> Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
> >>>> R-Car), having a separate CSC can give more precision (as well as
> >>>> allowing the two problems to be decoupled, at a relatively low hardware
> >>>> cost).  
> >>> If you put nonlinear signal to 3DLUT then your
> >>> precision would be improved.
> >>> How many bits each color value has in 3DLUT ?  
> >> The whole display pipeline uses 8 bits per component.  
> > It is pretty low , please, use always nonlinear signal in the pipe and it allows you to compress and 'win' about 2 bits.  

The DRM driver is not in control of that, though. Userspace controls it
through what values it happens to upload to the LUTs and matrices.

This raises a good point: userspace must be aware of both LUT
size and precision to decide if and how to use it.

> Do you have alpha and de-alpha blocks in your pipeline?
> You can do CSC and blending in nonlinear mode, it is less accurate than in linear, but it is viable way.

It may be viable in some cases and not others. That too is a userspace
decision.

> Also alpha should be removed (if it is applied) before CSC.

Right.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Alex Deucher]

On Thu, Sep 10, 2020 at 4:29 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel@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@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.
It had a primary plane and a cursor and gamma didn't apply to the
cursor.  The hardware supported by radeon goes back more than 20
years.

Alex


>
> > > The gamma LUT is currently used by some compositors to implement "night
> > > light"/redshift-like features.
> > >
> > > > Adding CSC and degamma LUT properties for each plane as well as a gamma
> > > > LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> > > > entirely on userspace to fill in those tables. But userspace has to know
> > > > how to generate those LUTs and colorspace conversion matrices in the
> > > > first place...
> > >
> > > So it wouldn't be enough for user-space to fill these gamma LUTs with
> > > linear ramps and get colors that look fine? Would the process be more
> > > involved? Would user-space need to know about the driver and generate
> > > gamma LUTs depending on the driver?
> > > That would be a show-stopper.
> >
> > Yeah we can't expose such an uapi, instead what I have in mind that the
> > in-kernel lut/csc for yuv/broadcast rgb and whatever else are mixed in
> > with what userspace provides. That means a slight loss of precision and
> > we'll have to have a nice fixed point math library for this stuff in the
> > kernel. But color correction hw is too special between vendors that I
> > don't think there's any other solution. E.g. even on intel we sometimes
> > have dedicated register bits/hw functions for yuv/rgb broadcast value
> > range and whatever else, and on other platforms we need to do that by
> > adjusting the lut/csc.
>
> Yeah, that makes sense to me.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Ville Syrjälä]

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@emersion.fr> wrote:
> >
> > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel@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@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?".

> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Alex Deucher]

On Mon, Sep 14, 2020 at 9:32 AM Ville Syrjälä
<ville.syrjala@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@emersion.fr> wrote:
> > >
> > > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: per-plane LUTs and CSCs?

[Ville Syrjälä]

On Mon, Sep 14, 2020 at 10:38:24AM -0400, Alex Deucher wrote:
> On Mon, Sep 14, 2020 at 9:32 AM Ville Syrjälä
> <ville.syrjala@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@emersion.fr> wrote:
> > > >
> > > > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel@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@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.

Right. Windows didn't have use for overlay planes so a lot of hw
lost them around that time I guess. Intel hw didn't quite lose them,
but they did lose a bunch of features such as scaling and planar
YCbCr formats. And at least in our case most of the lost stuff has
been reintroduced in recent years after Android/Windows started to
use them again. Which is fine by me since I can often use ancient
hw to bring up some of the "new" features in the latest hw ;)

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel