From: Harry Wentland <harry.wentland@amd.com>
To: Brian Starkey <brian.starkey@arm.com>,
"Sharma, Shashank" <shashank.sharma@amd.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
ppaalanen@gmail.com, sebastian@sebastianwick.net,
mcasas@google.com, jshargo@google.com, Deepak.Sharma@amd.com,
Shirish.S@amd.com, Vitaly.Prosyak@amd.com, aric.cyr@amd.com,
Bhawanpreet.Lakha@amd.com, Krunoslav.Kovac@amd.com,
hersenxs.wu@amd.com, Nicholas.Kazlauskas@amd.com,
laurentiu.palcu@oss.nxp.com, ville.syrjala@linux.intel.com,
nd@arm.com, uma.shankar@intel.com
Subject: Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
Date: Mon, 16 Aug 2021 08:40:14 -0400 [thread overview]
Message-ID: <ace8dcf8-fe01-ad1e-8cfb-92e559f01d2f@amd.com> (raw)
In-Reply-To: <20210816111029.74cisnhblllindcv@000377403353>
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
>> Hello Brian,
>> (+Uma in cc)
>>
>> Thanks for your comments, Let me try to fill-in for Harry to keep the design
>> discussion going. Please find my comments inline.
>>
Thanks, Shashank. I'm back at work now. Had to cut my trip short
due to rising Covid cases and concern for my kids.
>> On 8/2/2021 10:00 PM, Brian Starkey wrote:
>>>
>
> -- snip --
>
>>>
>>> Android doesn't blend in linear space, so any API shouldn't be built
>>> around an assumption of linear blending.
>>>
This seems incorrect but I guess ultimately the OS is in control of
this. If we want to allow blending in non-linear space with the new
API we would either need to describe the blending space or the
pre/post-blending gamma/de-gamma.
Any idea if this blending behavior in Android might get changed in
the future?
>>
>> If I am not wrong, we still need linear buffers for accurate Gamut
>> transformation (SRGB -> BT2020 or other way around) isn't it ?
>
> Yeah, you need to transform the buffer to linear for color gamut
> conversions, but then back to non-linear (probably sRGB or gamma 2.2)
> for actual blending.
>
> This is why I'd like to have the per-plane "OETF/GAMMA" separate
> from tone-mapping, so that the composition transfer function is
> independent.
>
>>
>
> ...
>
>>>> +
>>>> +Tonemapping in this case could be a simple nits value or `EDR`_ to describe
>>>> +how to scale the :ref:`SDR luminance`.
>>>> +
>>>> +Tonemapping could also include the ability to use a 3D LUT which might be
>>>> +accompanied by a 1D shaper LUT. The shaper LUT is required in order to
>>>> +ensure a 3D LUT with limited entries (e.g. 9x9x9, or 17x17x17) operates
>>>> +in perceptual (non-linear) space, so as to evenly spread the limited
>>>> +entries evenly across the perceived space.
>>>
>>> Some terminology care may be needed here - up until this point, I
>>> think you've been talking about "tonemapping" being luminance
>>> adjustment, whereas I'd expect 3D LUTs to be used for gamut
>>> adjustment.
>>>
>>
>> IMO, what harry wants to say here is that, which HW block gets picked and
>> how tone mapping is achieved can be a very driver/HW specific thing, where
>> one driver can use a 1D/Fixed function block, whereas another one can choose
>> more complex HW like a 3D LUT for the same.
>>
>> DRM layer needs to define only the property to hook the API with core
>> driver, and the driver can decide which HW to pick and configure for the
>> activity. So when we have a tonemapping property, we might not have a
>> separate 3D-LUT property, or the driver may fail the atomic_check() if both
>> of them are programmed for different usages.
>
> I still think that directly exposing the HW blocks and their
> capabilities is the right approach, rather than a "magic" tonemapping
> property.
>
> Yes, userspace would need to have a good understanding of how to use
> that hardware, but if the pipeline model is standardised that's the
> kind of thing a cross-vendor library could handle.
>
One problem with cross-vendor libraries is that they might struggle
to really be cross-vendor when it comes to unique HW behavior. Or
they might pick sub-optimal configurations as they're not aware of
the power impact of a configuration. What's an optimal configuration
might differ greatly between different HW.
We're seeing this problem with "universal" planes as well.
> It would definitely be good to get some compositor opinions here.
>
For this we'll probably have to wait for Pekka's input when he's
back from his vacation.
> Cheers,
> -Brian
>
next prev parent reply other threads:[~2021-08-16 12:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 20:41 [RFC PATCH v3 0/6] A drm_plane API to support HDR planes Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC Harry Wentland
2021-08-02 16:30 ` Brian Starkey
2021-08-13 5:12 ` Sharma, Shashank
2021-08-16 11:10 ` Brian Starkey
2021-08-16 12:40 ` Harry Wentland [this message]
2021-08-16 13:37 ` sebastian
2021-09-06 21:20 ` Shankar, Uma
2021-09-15 14:36 ` Pekka Paalanen
2021-09-21 1:55 ` Harry Wentland
2021-09-15 14:01 ` Pekka Paalanen
2021-09-15 15:50 ` Jeremy Cline
2021-09-21 0:14 ` Harry Wentland
2021-09-21 13:31 ` Pekka Paalanen
2021-09-21 18:05 ` Harry Wentland
2021-09-22 8:31 ` Pekka Paalanen
2021-09-22 15:28 ` Harry Wentland
2021-09-23 7:43 ` Pekka Paalanen
2021-09-30 13:04 ` Repository for additional color and HDR related documentation (Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC) Pekka Paalanen
2021-09-22 15:06 ` [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC Harry Wentland
2021-09-23 8:01 ` Pekka Paalanen
2021-09-23 13:40 ` Harry Wentland
2021-09-23 15:50 ` Vitaly Prosyak
2021-07-30 20:41 ` [RFC PATCH v3 2/6] drm/color: Add transfer functions for HDR/SDR on drm_plane Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 3/6] drm/color: Add output transfer function to crtc Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 4/6] drm/color: Add sdr boost property Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 5/6] drm/color: Add color space plane property Harry Wentland
2021-07-30 20:41 ` [RFC PATCH v3 6/6] drm/amd/display: reformat YCbCr-RGB conversion matrix Harry Wentland
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=ace8dcf8-fe01-ad1e-8cfb-92e559f01d2f@amd.com \
--to=harry.wentland@amd.com \
--cc=Bhawanpreet.Lakha@amd.com \
--cc=Deepak.Sharma@amd.com \
--cc=Krunoslav.Kovac@amd.com \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=Shirish.S@amd.com \
--cc=Vitaly.Prosyak@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=aric.cyr@amd.com \
--cc=brian.starkey@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hersenxs.wu@amd.com \
--cc=jshargo@google.com \
--cc=laurentiu.palcu@oss.nxp.com \
--cc=mcasas@google.com \
--cc=nd@arm.com \
--cc=ppaalanen@gmail.com \
--cc=sebastian@sebastianwick.net \
--cc=shashank.sharma@amd.com \
--cc=uma.shankar@intel.com \
--cc=ville.syrjala@linux.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).