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.syrj...@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 <cont...@emersion.fr> wrote: > > > > > > > > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter > > > > <dan...@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.pa...@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
