From: Harry Wentland <harry.wentland@amd.com>
To: Pekka Paalanen <ppaalanen@gmail.com>,
Sebastian Wick <sebastian.wick@redhat.com>
Cc: "Aleix Pol" <aleixpol@kde.org>,
"Sasha McIntosh" <sashamcintosh@google.com>,
"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
"Shashank Sharma" <shashank.sharma@amd.com>,
"Xaver Hugl" <xaver.hugl@gmail.com>,
"Hector Martin" <marcan@marcan.st>,
"Liviu Dudau" <Liviu.Dudau@arm.com>,
"Victoria Brekenfeld" <victoria@system76.com>,
dri-devel@lists.freedesktop.org,
wayland-devel@lists.freedesktop.org,
"Melissa Wen" <mwen@igalia.com>,
"Michel Dänzer" <mdaenzer@redhat.com>,
"Jonas Ådahl" <jadahl@redhat.com>,
"Joshua Ashton" <joshua@froggi.es>,
"Naseer Ahmed" <quic_naseer@quicinc.com>,
"Uma Shankar" <uma.shankar@intel.com>,
"Christopher Braga" <quic_cbraga@quicinc.com>,
"Arthur Grillo" <arthurgrillo@riseup.net>
Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
Date: Fri, 20 Oct 2023 11:23:28 -0400 [thread overview]
Message-ID: <20f33898-4c40-4854-a1e8-afaef52f6524@amd.com> (raw)
In-Reply-To: <20231020175703.09cd2578@eldfell>
On 2023-10-20 10:57, Pekka Paalanen wrote:
> On Fri, 20 Oct 2023 16:22:56 +0200
> Sebastian Wick <sebastian.wick@redhat.com> wrote:
>
>> Thanks for continuing to work on this!
>>
>> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:
>>> v2:
>>> - Update colorop visualizations to match reality (Sebastian, Alex Hung)
>>> - Updated wording (Pekka)
>>> - Change BYPASS wording to make it non-mandatory (Sebastian)
>>> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
>>> section (Pekka)
>>> - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa)
>>> - Add "Driver Implementer's Guide" section (Pekka)
>>> - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka)
>>>
>
> ...
>
>>> +Driver Forward/Backward Compatibility
>>> +=====================================
>>> +
>>> +As this is uAPI drivers can't regress color pipelines that have been
>>> +introduced for a given HW generation. New HW generations are free to
>>> +abandon color pipelines advertised for previous generations.
>>> +Nevertheless, it can be beneficial to carry support for existing color
>>> +pipelines forward as those will likely already have support in DRM
>>> +clients.
>>> +
>>> +Introducing new colorops to a pipeline is fine, as long as they can be
>>> +disabled or are purely informational. DRM clients implementing support
>>> +for the pipeline can always skip unknown properties as long as they can
>>> +be confident that doing so will not cause unexpected results.
>>> +
>>> +If a new colorop doesn't fall into one of the above categories
>>> +(bypassable or informational) the modified pipeline would be unusable
>>> +for user space. In this case a new pipeline should be defined.
>>
>> How can user space detect an informational element? Should we just add a
>> BYPASS property to informational elements, make it read only and set to
>> true maybe? Or something more descriptive?
>
> Read-only BYPASS set to true would be fine by me, I guess.
>
Don't you mean set to false? An informational element will always do
something, so it can't be bypassed.
> I think we also need a definition of "informational".
>
> Counter-example 1: a colorop that represents a non-configurable
Not sure what's "counter" for these examples?
> YUV<->RGB conversion. Maybe it determines its operation from FB pixel
> format. It cannot be set to bypass, it cannot be configured, and it
> will alter color values.
>
> Counter-example 2: image size scaling colorop. It might not be
> configurable, it is controlled by the plane CRTC_* and SRC_*
> properties. You still need to understand what it does, so you can
> arrange the scaling to work correctly. (Do not want to scale an image
> with PQ-encoded values as Josh demonstrated in XDC.)
>
IMO the position of the scaling operation is the thing that's important
here as the color pipeline won't define scaling properties.
> Counter-example 3: image sampling colorop. Averages FB originated color
> values to produce a color sample. Again do not want to do this with
> PQ-encoded values.
>
Wouldn't this only happen during a scaling op?
Harry
>
> Thanks,
> pq
next prev parent reply other threads:[~2023-10-20 15:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 21:21 [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 01/17] drm/atomic: Allow get_value for immutable properties on atomic drivers Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 02/17] drm: Don't treat 0 as -1 in drm_fixp2int_ceil Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 03/17] drm/vkms: Create separate Kconfig file for VKMS Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 04/17] drm/vkms: Add kunit tests for VKMS LUT handling Harry Wentland
2023-10-23 22:34 ` Arthur Grillo
2023-10-19 21:21 ` [RFC PATCH v2 05/17] drm/vkms: Avoid reading beyond LUT array Harry Wentland
2023-10-30 13:29 ` Pekka Paalanen
2023-11-06 20:48 ` Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed Harry Wentland
2023-10-20 14:22 ` Sebastian Wick
2023-10-20 14:57 ` Pekka Paalanen
2023-10-20 15:23 ` Harry Wentland [this message]
2023-10-23 8:12 ` Pekka Paalanen
2023-10-25 20:16 ` Alex Goins
2023-10-26 8:57 ` Pekka Paalanen
2023-10-26 17:30 ` Sebastian Wick
2023-10-26 19:25 ` Alex Goins
2023-10-27 8:59 ` Michel Dänzer
2023-10-27 10:01 ` Sebastian Wick
2023-10-27 12:01 ` Pekka Paalanen
2023-11-04 23:01 ` Christopher Braga
2023-11-07 16:52 ` Harry Wentland
2023-11-07 16:52 ` Harry Wentland
2023-11-07 16:52 ` Harry Wentland
2023-11-07 21:17 ` Sebastian Wick
2023-11-07 16:52 ` Harry Wentland
2023-11-07 16:52 ` Harry Wentland
2023-11-08 12:18 ` Shankar, Uma
2023-11-08 13:43 ` Joshua Ashton
2023-11-09 10:17 ` Shankar, Uma
2023-11-09 11:55 ` Pekka Paalanen
2023-11-10 11:27 ` Shankar, Uma
2023-11-10 13:27 ` Pekka Paalanen
2023-11-08 14:37 ` Harry Wentland
2023-11-09 10:24 ` Shankar, Uma
2023-10-19 21:21 ` [RFC PATCH v2 07/17] drm/colorop: Introduce new drm_colorop mode object Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 08/17] drm/colorop: Add TYPE property Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 09/17] drm/color: Add 1D Curve subtype Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 10/17] drm/colorop: Add BYPASS property Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 11/17] drm/colorop: Add NEXT property Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 12/17] drm/colorop: Add atomic state print for drm_colorop Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 13/17] drm/colorop: Add new IOCTLs to retrieve drm_colorop objects Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 14/17] drm/plane: Add COLOR PIPELINE property Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 15/17] drm/colorop: Add NEXT to colorop state print Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 16/17] drm/vkms: Add enumerated 1D curve colorop Harry Wentland
2023-10-19 21:21 ` [RFC PATCH v2 17/17] drm/vkms: Add kunit tests for linear and sRGB LUTs Harry Wentland
2023-11-08 11:54 ` [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS Shankar, Uma
2023-11-08 14:32 ` 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=20f33898-4c40-4854-a1e8-afaef52f6524@amd.com \
--to=harry.wentland@amd.com \
--cc=Liviu.Dudau@arm.com \
--cc=aleixpol@kde.org \
--cc=arthurgrillo@riseup.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=jadahl@redhat.com \
--cc=joshua@froggi.es \
--cc=marcan@marcan.st \
--cc=mdaenzer@redhat.com \
--cc=mwen@igalia.com \
--cc=ppaalanen@gmail.com \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_cbraga@quicinc.com \
--cc=quic_naseer@quicinc.com \
--cc=sashamcintosh@google.com \
--cc=sebastian.wick@redhat.com \
--cc=shashank.sharma@amd.com \
--cc=uma.shankar@intel.com \
--cc=victoria@system76.com \
--cc=wayland-devel@lists.freedesktop.org \
--cc=xaver.hugl@gmail.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).