dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Harry Wentland <harry.wentland@amd.com>
Cc: Deepak.Sharma@amd.com, Krunoslav.Kovac@amd.com,
	mcasas@google.com, Shashank.Sharma@amd.com,
	dri-devel@lists.freedesktop.org, Shirish.S@amd.com,
	Sebastian Wick <sebastian@sebastianwick.net>,
	Uma Shankar <uma.shankar@intel.com>,
	hersenxs.wu@amd.com, amd-gfx@lists.freedesktop.org,
	laurentiu.palcu@oss.nxp.com, Bhawanpreet.Lakha@amd.com,
	Nicholas.Kazlauskas@amd.com, Vitaly.Prosyak@amd.com
Subject: Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings
Date: Wed, 19 May 2021 10:56:25 +0300	[thread overview]
Message-ID: <20210519105625.01e99f41@eldfell> (raw)
In-Reply-To: <812996ec-13f0-2440-c3d0-efb21fd877e5@amd.com>

[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]

On Tue, 18 May 2021 10:32:48 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2021-05-17 4:34 a.m., Pekka Paalanen wrote:
> > On Fri, 14 May 2021 17:04:51 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >   
> >> On 2021-04-30 8:53 p.m., Sebastian Wick wrote:  
> >>> On 2021-04-26 20:56, Harry Wentland wrote:    
> > 
> > ...
> >   
> >>>> Another reason I'm proposing to define the color space (and gamma) of
> >>>> a plane is to make this explicit. Up until the color space and gamma
> >>>> of a plane or framebuffer are not well defined, which leads to drivers
> >>>> assuming the color space and gamma of a buffer (for blending and other
> >>>> purposes) and might lead to sub-optimal outcomes.    
> >>>
> >>> Blending only is "correct" with linear light so that property of the
> >>> color space is important. However, why does the kernel have to be
> >>> involved here? As long as user space knows that for correct blending the
> >>> data must represent linear light and knows when in the pipeline blending
> >>> happens it can make sure that the data at that point in the pipeline
> >>> contains linear light.
> >>>     
> >>
> >> The only reason the kernel needs to be involved is to take full advantage
> >> of the available HW without requiring KMS clients to be aware of
> >> the difference in display HW.  
> > 
> > Can you explain in more tangible examples, why you think so, please?
> > 
> > Is it because hardware does not fit the KMS UAPI model of the abstract
> > pixel pipeline?
> >   
> 
> I'd wager no HW is designed to meet KMS UAPI, rather KMS UAPI is designed
> to abstract HW.

Of course, but you are in big trouble in any case if there is a
fundamental mismatch. You may have to declare that all existing KMS
properties for this stuff will be mutually exclusive with your new
properties, so that you can introduce a new generic abstract pipeline
in KMS.

By mutually exclusive I mean that a driver must advertise only one or
the other set of properties and never both. If you want to support
userspace that doesn't understand the alternative set, maybe you also
need a drm client cap to switch to the alternative set per-drm-client.

> > Or is it because you have fixed-function hardware elements that you can
> > only make use of when userspace uses an enum-based UAPI?
> >   
> 
> One example is our degamma on our latest generation HW, where we have
> fixed-function "degamma" (rather de-EOTF):
> 
> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c#L166

Ok.

> > I would totally agree that the driver does not want to be analysing LUT
> > entries to decipher if it could use a fixed-function element or not. It
> > would introduce uncertainty in the UAPI. So fixed-function elements
> > would need their own properties, but I don't know if that is feasible
> > as generic UAPI or if it should be driver-specific (and so left unused
> > by generic userspace).
> >   
> 
> 
> For the CRTC LUTs we actually do a linearity check to program the
> HW into bypass when the LUT is linear since the KMS LUT definition
> doesn't map well onto the LUT definition used by our HW and leads
> to rounding errors and failing IGT kms_color tests (if I remember
> this correctly).
> 
> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c#L330
> 
> Hence the suggestion to define pre-defined TFs right at a KMS level
> for usecases where we can assume the display will tonemap the 
> content.

Right. Explaining this would have been a good introduction in your
cover letter.

Maybe you want to define new KMS properties that shall be mutually
exclusive with the existing KMS GAMMA/CTM/DEGAMMA properties and
clearly document them as such.


Thanks,
pq

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

  reply	other threads:[~2021-05-19  7:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26 17:38 [RFC PATCH 0/3] A drm_plane API to support HDR planes Harry Wentland
2021-04-26 17:38 ` [RFC PATCH 1/3] drm/color: Add RGB Color encodings Harry Wentland
2021-04-26 18:07   ` Ville Syrjälä
2021-04-26 18:56     ` Harry Wentland
2021-04-26 19:08       ` Ville Syrjälä
2021-04-30  9:04         ` Pekka Paalanen
2021-05-01  0:53       ` Sebastian Wick
2021-05-14 21:04         ` Harry Wentland
2021-05-17  8:34           ` Pekka Paalanen
2021-05-18 14:32             ` Harry Wentland
2021-05-19  7:56               ` Pekka Paalanen [this message]
2021-04-26 17:38 ` [RFC PATCH 2/3] drm/color: Add Color transfer functions for HDR/SDR Harry Wentland
2021-04-26 17:38 ` [RFC PATCH 3/3] drm/color: Add sdr boost property Harry Wentland
2021-04-27  9:09 ` [RFC PATCH 0/3] A drm_plane API to support HDR planes Daniel Vetter
2021-04-27 14:50 ` Pekka Paalanen
2021-04-28  7:54   ` Shashank Sharma
2021-04-30  9:43     ` Pekka Paalanen
2021-04-30 10:39       ` Shashank Sharma
2021-05-14 21:01         ` Harry Wentland
2021-05-14 21:05   ` Harry Wentland
2021-05-17  8:57     ` Pekka Paalanen
2021-05-17 16:48       ` Sebastian Wick
2021-05-17 19:39         ` Vitaly Prosyak
2021-05-18  7:56           ` Pekka Paalanen
2021-05-18 14:19             ` Harry Wentland
2021-05-18 23:00               ` Sebastian Wick
2021-05-19  8:53               ` Pekka Paalanen
2021-05-19 10:02                 ` Pekka Paalanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210519105625.01e99f41@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=Bhawanpreet.Lakha@amd.com \
    --cc=Deepak.Sharma@amd.com \
    --cc=Krunoslav.Kovac@amd.com \
    --cc=Nicholas.Kazlauskas@amd.com \
    --cc=Shashank.Sharma@amd.com \
    --cc=Shirish.S@amd.com \
    --cc=Vitaly.Prosyak@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=hersenxs.wu@amd.com \
    --cc=laurentiu.palcu@oss.nxp.com \
    --cc=mcasas@google.com \
    --cc=sebastian@sebastianwick.net \
    --cc=uma.shankar@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).