On Thu, 10 Sep 2020 15:39:07 -0400 Vitaly Prosyak <vitaly.prosyak@xxxxxxx> 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:
pgphIG2UO7uhV.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
