Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On Thu, 03 Jun 2021 14:30:41 +0200 Sebastian Wick wrote: > On 2021-06-03 10:47, Pekka Paalanen wrote: > > On Wed, 2 Jun 2021 19:42:19 -0400 > > Harry Wentland wrote: > > > >> On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > >> > > >> > > >> >> -Original Message- > >> >> From: Pekka Paalanen > >> >> Sent: Wednesday, June 2, 2021 2:59 PM > >> >> To: Shankar, Uma > >> >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > >> >> Modem, > >> >> Bhanuprakash ; Harry Wentland > >> >> > >> >> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC > >> >> features > >> >> > >> >> On Tue, 1 Jun 2021 16:21:57 +0530 > >> >> Uma Shankar wrote: > >> >> > >> >>> This is how a typical display color hardware pipeline looks like: > > > > ... > > > >> >>> This patch series adds properties for plane color features. It adds > >> >>> properties for degamma used to linearize data and CSC used for gamut > >> >>> conversion. It also includes Gamma support used to again non-linearize > >> >>> data as per panel supported color space. These can be utilize by user > >> >>> space to convert planes from one format to another, one color space to > >> >>> another etc. > >> >> > >> >> This is very much welcome! > >> >> > >> >> There is also the thread: > >> >> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>> > >> >> Everything mentioned will interact with each other by changing what the > >> >> abstract > >> >> KMS pixel pipeline does. I think you and Harry should probably look at > >> >> each others' > >> >> suggestions and see how to fit them all into a single abstract KMS > >> >> pipeline. > >> >> > >> >> People are adding new pieces into KMS left and right, and I fear we > >> >> lose sight of how > >> >> everything will actually work together when all KMS properties are > >> >> supposed to be > >> >> generic and potentially present simultaneously. This is why I would > >> >> very much like to > >> >> have that *whole* abstract KMS pipeline documented with *everything*. > >> >> Otherwise > >> >> it is coming really hard fast to figure out how generic userspace > >> >> should use all these > >> >> KMS properties together. > >> >> > >> >> Or if there cannot be a single abstract KMS pipeline, then sure, have > >> >> multiple, as long > >> >> as they are documented and how userspace will know which pipeline it is > >> >> dealing > >> >> with, and what things are mutually exclusive so we can avoid writing > >> >> userspace code > >> >> for combinations that will never exist. > >> > > >> > This is a good suggestion to have the whole pipeline and properties > >> > documented along with > >> > the exact usages. We may end with 2 properties almost doing similar work > >> > but needed due to > >> > underlying hardware, but we can get that properly documented and defined. > >> > > >> > I will discuss with Harry and Ville as well to define this. > >> > > >> > >> Just wanted to let you know that I've seen and read through both of > >> Shankar's patchsets > >> and had some thoughts but haven't found the time to respond. I will > >> respond soon. > > > > Hi Harry, > > > > awesome! > > > >> I very much agree with Pekka. We need to make sure this all plays well > >> together and is > >> well documented. Maybe a library to deal with DRM KMS color > >> management/HDR would even > >> be helpful. Not sure yet how I feel about that. > > > > That is an excellent question. While I am working on Weston CM, I > > already have issues with how to represent the color related > > transformations. These new hardware features exposed here are nothing I > > have prepared for, and would probably need changes to accommodate. > > > > The main Weston roadmap is drafted in > > https://gitlab.freedesktop.org/wayland
Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On 2021-06-03 10:47, Pekka Paalanen wrote: On Wed, 2 Jun 2021 19:42:19 -0400 Harry Wentland wrote: On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 2:59 PM >> To: Shankar, Uma >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem, >> Bhanuprakash ; Harry Wentland >> >> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features >> >> On Tue, 1 Jun 2021 16:21:57 +0530 >> Uma Shankar wrote: >> >>> This is how a typical display color hardware pipeline looks like: ... >>> This patch series adds properties for plane color features. It adds >>> properties for degamma used to linearize data and CSC used for gamut >>> conversion. It also includes Gamma support used to again non-linearize >>> data as per panel supported color space. These can be utilize by user >>> space to convert planes from one format to another, one color space to >>> another etc. >> >> This is very much welcome! >> >> There is also the thread: >> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>> >> Everything mentioned will interact with each other by changing what the abstract >> KMS pixel pipeline does. I think you and Harry should probably look at each others' >> suggestions and see how to fit them all into a single abstract KMS pipeline. >> >> People are adding new pieces into KMS left and right, and I fear we lose sight of how >> everything will actually work together when all KMS properties are supposed to be >> generic and potentially present simultaneously. This is why I would very much like to >> have that *whole* abstract KMS pipeline documented with *everything*. Otherwise >> it is coming really hard fast to figure out how generic userspace should use all these >> KMS properties together. >> >> Or if there cannot be a single abstract KMS pipeline, then sure, have multiple, as long >> as they are documented and how userspace will know which pipeline it is dealing >> with, and what things are mutually exclusive so we can avoid writing userspace code >> for combinations that will never exist. > > This is a good suggestion to have the whole pipeline and properties documented along with > the exact usages. We may end with 2 properties almost doing similar work but needed due to > underlying hardware, but we can get that properly documented and defined. > > I will discuss with Harry and Ville as well to define this. > Just wanted to let you know that I've seen and read through both of Shankar's patchsets and had some thoughts but haven't found the time to respond. I will respond soon. Hi Harry, awesome! I very much agree with Pekka. We need to make sure this all plays well together and is well documented. Maybe a library to deal with DRM KMS color management/HDR would even be helpful. Not sure yet how I feel about that. That is an excellent question. While I am working on Weston CM, I already have issues with how to represent the color related transformations. These new hardware features exposed here are nothing I have prepared for, and would probably need changes to accommodate. The main Weston roadmap is drafted in https://gitlab.freedesktop.org/wayland/weston/-/issues/467 The MR that introduces the concept of a color transformation, and also the whole beginnings of color management, is https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582 In that MR, there is a patch introducing struct weston_color_transform: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582/diffs?commit_id=cffbf7c6b2faf7391b73ff9202774f660343bd34#ba0b86259533d5000d81c9c88109c9010eb0f641_0_77 The design idea there is that libweston shall have what I call "color manager" module. That module handles all the policy decisions about color, it uses a CMM (Little CMS 2 in this case) for all the color profile computations, and based on all information it has available from display EDID, ICC profile files, Wayland clients via the CM protocol extension and more, it will ultimately produce weston_color_transform objects. weston_color_transform is a complete description of how to map a pixel in one color model/space/encoding into another, maybe with user preferred tuning/tone-mapping. E.g. from client content to the output's blending space (output space but light-linear), or from output's blending space to output's framebuffer space or maybe even monitor wire space. The mapping described by weston_color_transform shall be implemented by libweston's GL-renderer or by the DRM-backend using KMS properties, whatever works for each case. So the description cannot b
Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On Wed, 2 Jun 2021 19:42:19 -0400 Harry Wentland wrote: > On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > > > > >> -Original Message- > >> From: Pekka Paalanen > >> Sent: Wednesday, June 2, 2021 2:59 PM > >> To: Shankar, Uma > >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > >> Modem, > >> Bhanuprakash ; Harry Wentland > >> > >> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features > >> > >> On Tue, 1 Jun 2021 16:21:57 +0530 > >> Uma Shankar wrote: > >> > >>> This is how a typical display color hardware pipeline looks like: ... > >>> This patch series adds properties for plane color features. It adds > >>> properties for degamma used to linearize data and CSC used for gamut > >>> conversion. It also includes Gamma support used to again non-linearize > >>> data as per panel supported color space. These can be utilize by user > >>> space to convert planes from one format to another, one color space to > >>> another etc. > >> > >> This is very much welcome! > >> > >> There is also the thread: > >> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>> > >> Everything mentioned will interact with each other by changing what the > >> abstract > >> KMS pixel pipeline does. I think you and Harry should probably look at > >> each others' > >> suggestions and see how to fit them all into a single abstract KMS > >> pipeline. > >> > >> People are adding new pieces into KMS left and right, and I fear we lose > >> sight of how > >> everything will actually work together when all KMS properties are > >> supposed to be > >> generic and potentially present simultaneously. This is why I would very > >> much like to > >> have that *whole* abstract KMS pipeline documented with *everything*. > >> Otherwise > >> it is coming really hard fast to figure out how generic userspace should > >> use all these > >> KMS properties together. > >> > >> Or if there cannot be a single abstract KMS pipeline, then sure, have > >> multiple, as long > >> as they are documented and how userspace will know which pipeline it is > >> dealing > >> with, and what things are mutually exclusive so we can avoid writing > >> userspace code > >> for combinations that will never exist. > > > > This is a good suggestion to have the whole pipeline and properties > > documented along with > > the exact usages. We may end with 2 properties almost doing similar work > > but needed due to > > underlying hardware, but we can get that properly documented and defined. > > > > I will discuss with Harry and Ville as well to define this. > > > > Just wanted to let you know that I've seen and read through both of Shankar's > patchsets > and had some thoughts but haven't found the time to respond. I will respond > soon. Hi Harry, awesome! > I very much agree with Pekka. We need to make sure this all plays well > together and is > well documented. Maybe a library to deal with DRM KMS color management/HDR > would even > be helpful. Not sure yet how I feel about that. That is an excellent question. While I am working on Weston CM, I already have issues with how to represent the color related transformations. These new hardware features exposed here are nothing I have prepared for, and would probably need changes to accommodate. The main Weston roadmap is drafted in https://gitlab.freedesktop.org/wayland/weston/-/issues/467 The MR that introduces the concept of a color transformation, and also the whole beginnings of color management, is https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582 In that MR, there is a patch introducing struct weston_color_transform: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582/diffs?commit_id=cffbf7c6b2faf7391b73ff9202774f660343bd34#ba0b86259533d5000d81c9c88109c9010eb0f641_0_77 The design idea there is that libweston shall have what I call "color manager" module. That module handles all the policy decisions about color, it uses a CMM (Little CMS 2 in this case) for all the color profile computations, and based on all information it has available from display EDID, ICC profile files, Wayland clients via the CM protocol extension and more, it will ultimately produce weston_color_transform objects. weston_color_transform is a complete description of how to map a pixel in one color model/space/encodin
Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 2:59 PM >> To: Shankar, Uma >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem, >> Bhanuprakash ; Harry Wentland >> >> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features >> >> On Tue, 1 Jun 2021 16:21:57 +0530 >> Uma Shankar wrote: >> >>> This is how a typical display color hardware pipeline looks like: >>> +---+ >>> |RAM| >>> | +--++-++-+ | >>> | | FB 1 || FB 2 || FB N| | >>> | +--++-++-+ | >>> +---+ >>>| Plane Color Hardware Block | >>> ++ >>> | +---v-+ +---v---+ +---v--+ | >>> | | Plane A | | Plane B | | Plane N | | >>> | | DeGamma | | Degamma | | Degamma | | >>> | +---+-+ +---+---+ +---+--+ | >>> | | | || >>> | +---v-+ +---v---+ +---v--+ | >>> | |Plane A | | Plane B | | Plane N | | >>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | | >>> | +---+-+ ++--+ ++-+ | >>> | | | | | >>> | +---v-+ +v--+ +v-+ | >>> | | Plane A | | Plane B | | Plane N | | >>> | | Gamma | | Gamma | | Gamma| | >>> | +---+-+ ++--+ ++-+ | >>> | | | | | >>> ++ >>> +--v--v---v---| >>> || || >>> || Pipe Blender|| >>> +++ >>> ||| >>> |+---v--+ | >>> || Pipe DeGamma| | >>> || | | >>> |+---+--+ | >>> ||Pipe Color | >>> |+---v--+ Hardware| >>> || Pipe CSC/CTM| | >>> || | | >>> |+---+--+ | >>> ||| >>> |+---v--+ | >>> || Pipe Gamma | | >>> || | | >>> |+---+--+ | >>> ||| >>> +-+ >>> | >>> v >>>Pipe Output >> >> Hi, >> >> this is an excellent picture. I have long been wanting schematics like that >> in the DRM >> UAPI documentation. Another note on that: >> https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html>>> >> But the schematic for DRM UAPI documentation needs to be written in terms of >> the >> abstract KMS pipeline with property names spelled out, like in what Ville >> sketched in >> that email. > > Sure Pekka, I can add that. > >>> This patch series adds properties for plane color features. It adds >>> properties for degamma used to linearize data and CSC used for gamut >>> conversion. It also includes Gamma support used to again non-linearize >>> data as per panel supported color space. These can be utilize by user >>> space to convert planes from one format to another, one color space to >>> another etc. >> >> This is very much welcome! >> >> There is also the thread: >> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>> >> Everything mentioned will interact with each other by changing what the >> abstract >> KMS pixel pipeline does. I think you and Harry should probably look at each >> others' >> suggestions and see how to fit them all into a single abstract KMS pipeline. >> >> People are adding new pieces into KMS left and right, and I fear we lose >> sig
RE: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:59 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem, > Bhanuprakash ; Harry Wentland > > Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features > > On Tue, 1 Jun 2021 16:21:57 +0530 > Uma Shankar wrote: > > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > Hi, > > this is an excellent picture. I have long been wanting schematics like that > in the DRM > UAPI documentation. Another note on that: > https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html > > But the schematic for DRM UAPI documentation needs to be written in terms of > the > abstract KMS pipeline with property names spelled out, like in what Ville > sketched in > that email. Sure Pekka, I can add that. > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > This is very much welcome! > > There is also the thread: > https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html > > Everything mentioned will interact with each other by changing what the > abstract > KMS pixel pipeline does. I think you and Harry should probably look at each > others' > suggestions and see how to fit them all into a single abstract KMS pipeline. > > People are adding new pieces into KMS left and right, and I fear we lose > sight of how > everything will actually work together when all KMS properties are supposed > to be > generic and potentially present simultaneously. This is why I would very much > like to > have that *whole* abstract KMS pipeline documented with *everything*. > Otherwise > it is coming really hard fast to figure out how generic userspace should use > all t
Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On Tue, 1 Jun 2021 16:21:57 +0530 Uma Shankar wrote: > This is how a typical display color hardware pipeline looks like: > +---+ > |RAM| > | +--++-++-+ | > | | FB 1 || FB 2 || FB N| | > | +--++-++-+ | > +---+ >| Plane Color Hardware Block | > ++ > | +---v-+ +---v---+ +---v--+ | > | | Plane A | | Plane B | | Plane N | | > | | DeGamma | | Degamma | | Degamma | | > | +---+-+ +---+---+ +---+--+ | > | | | || > | +---v-+ +---v---+ +---v--+ | > | |Plane A | | Plane B | | Plane N | | > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > | +---+-+ ++--+ ++-+ | > | | | | | > | +---v-+ +v--+ +v-+ | > | | Plane A | | Plane B | | Plane N | | > | | Gamma | | Gamma | | Gamma| | > | +---+-+ ++--+ ++-+ | > | | | | | > ++ > +--v--v---v---| > || || > || Pipe Blender|| > +++ > ||| > |+---v--+ | > || Pipe DeGamma| | > || | | > |+---+--+ | > ||Pipe Color | > |+---v--+ Hardware| > || Pipe CSC/CTM| | > || | | > |+---+--+ | > ||| > |+---v--+ | > || Pipe Gamma | | > || | | > |+---+--+ | > ||| > +-+ > | > v >Pipe Output Hi, this is an excellent picture. I have long been wanting schematics like that in the DRM UAPI documentation. Another note on that: https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html But the schematic for DRM UAPI documentation needs to be written in terms of the abstract KMS pipeline with property names spelled out, like in what Ville sketched in that email. > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data and CSC used for gamut > conversion. It also includes Gamma support used to again non-linearize > data as per panel supported color space. These can be utilize by user > space to convert planes from one format to another, one color space to > another etc. This is very much welcome! There is also the thread: https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html Everything mentioned will interact with each other by changing what the abstract KMS pixel pipeline does. I think you and Harry should probably look at each others' suggestions and see how to fit them all into a single abstract KMS pipeline. People are adding new pieces into KMS left and right, and I fear we lose sight of how everything will actually work together when all KMS properties are supposed to be generic and potentially present simultaneously. This is why I would very much like to have that *whole* abstract KMS pipeline documented with *everything*. Otherwise it is coming really hard fast to figure out how generic userspace should use all these KMS properties together. Or if there cannot be a single abstract KMS pipeline, then sure, have multiple, as long as they are documented and how userspace will know which pipeline it is dealing with, and what things are mutually exclusive so we can avoid writing userspace code for combinations that will never exist. Thanks, pq > Userspace can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches add the property interfaces and enable helper functions. > This series adds Intel's XE_LPD hw specific plane gamma feature. We > can build up and add other platform/hardware specific implementation > on top of this series. > > Credits: Special mention and credits to Ville Syrjala for coming up > with a design for this feature and inputs. This series is based on > his original design and
