From: Harry Wentland <harry.wentland@amd.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: "Sasha McIntosh" <sashamcintosh@google.com>,
"Liviu Dudau" <Liviu.Dudau@arm.com>,
"Victoria Brekenfeld" <victoria@system76.com>,
dri-devel@lists.freedesktop.org,
"Michel Dänzer" <mdaenzer@redhat.com>,
"Arthur Grillo" <arthurgrillo@riseup.net>,
"Christopher Braga" <quic_cbraga@quicinc.com>,
"Sebastian Wick" <sebastian.wick@redhat.com>,
"Shashank Sharma" <shashank.sharma@amd.com>,
wayland-devel@lists.freedesktop.org,
"Jonas Ådahl" <jadahl@redhat.com>,
"Uma Shankar" <uma.shankar@intel.com>,
"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
"Naseer Ahmed" <quic_naseer@quicinc.com>,
"Melissa Wen" <mwen@igalia.com>, "Aleix Pol" <aleixpol@kde.org>,
"Hector Martin" <marcan@marcan.st>,
"Xaver Hugl" <xaver.hugl@gmail.com>,
"Joshua Ashton" <joshua@froggi.es>
Subject: Re: [RFC PATCH v2 05/17] drm/vkms: Avoid reading beyond LUT array
Date: Mon, 6 Nov 2023 15:48:13 -0500 [thread overview]
Message-ID: <4b0fd975-a2b8-4bfa-b06b-b08f704a099b@amd.com> (raw)
In-Reply-To: <20231030152928.02cd8301@eldfell>
On 2023-10-30 09:29, Pekka Paalanen wrote:
> On Thu, 19 Oct 2023 17:21:21 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> When the floor LUT index (drm_fixp2int(lut_index) is the last
>> index of the array the ceil LUT index will point to an entry
>> beyond the array. Make sure we guard against it and use the
>> value of the floot LUT index.
>>
>> Blurb about LUT creation and how first element should be 0x0 and
>> last one 0xffff.
>>
>> Hold on, is that even correct? What should the ends of a LUT be?
>> How does UNORM work and how does it apply to LUTs?
>
> Do you mean how should UNORM input value map to LUT entries for LUT
> indexing?
>
> I suppose UNORM 16-bit converts to nominal real values as:
> - 0x0: 0.0
> - 0xffff: 1.0
>
> And in LUT, you want 0.0 to map to the first LUT element exactly, and
> 1.0 to map to the last LUT element exactly, even if whatever
> interpolation may be in use, right?
>
> If so, it is important to make sure that, assuming linear interpolation
> for instance, there is no "dead zone" at either end. Given high
> interpolation precision, any step away from 0.0 or 1.0 needs to imply a
> change in the real-valued output, assuming e.g. identity LUT.
>
> If LUT has N elements, and 16-bit UNORM input value is I, then (in
> naive real-valued math, so no implicit truncation between operations)
>
> x = I / 0xffff * (N - 1)
> ia = floor(x)
> ib = min(ia + 1, N - 1)
>
> f = x - floor(x)
> y = (1 - f) * LUT[ia] + f * LUT[ib]
>
>
> Does that help?
>
Thanks. Yes, this is what the code is doing (with this commit).
The commit description was an oversight and only reflect my initial
thoughts when coding it, before I made sure this is the right way
to go about it. I'll update it.
Harry
> In my mind, I'm thinking of a uniformly distributed LUT as a 1-D
> texture, because that's how I have implemented them in GL. There you
> have to be careful so that input values 0.0 and 1.0 map to the *center*
> of the first and last texel, and not to the edges of the texture like
> texture coordinates do. Then you can use the GL linear texture
> interpolation as-is.
>
>
> Thanks,
> pq
>
>
>> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
>> Cc: Simon Ser <contact@emersion.fr>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Melissa Wen <mwen@igalia.com>
>> Cc: Jonas Ådahl <jadahl@redhat.com>
>> Cc: Sebastian Wick <sebastian.wick@redhat.com>
>> Cc: Shashank Sharma <shashank.sharma@amd.com>
>> Cc: Alexander Goins <agoins@nvidia.com>
>> Cc: Joshua Ashton <joshua@froggi.es>
>> Cc: Michel Dänzer <mdaenzer@redhat.com>
>> Cc: Aleix Pol <aleixpol@kde.org>
>> Cc: Xaver Hugl <xaver.hugl@gmail.com>
>> Cc: Victoria Brekenfeld <victoria@system76.com>
>> Cc: Sima <daniel@ffwll.ch>
>> Cc: Uma Shankar <uma.shankar@intel.com>
>> Cc: Naseer Ahmed <quic_naseer@quicinc.com>
>> Cc: Christopher Braga <quic_cbraga@quicinc.com>
>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Cc: Arthur Grillo <arthurgrillo@riseup.net>
>> Cc: Hector Martin <marcan@marcan.st>
>> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
>> Cc: Sasha McIntosh <sashamcintosh@google.com>
>> ---
>> drivers/gpu/drm/vkms/vkms_composer.c | 14 ++++++++++----
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c
>> index a0a3a6fd2926..cf1dff162920 100644
>> --- a/drivers/gpu/drm/vkms/vkms_composer.c
>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
>> @@ -123,6 +123,8 @@ static u16 apply_lut_to_channel_value(const struct vkms_color_lut *lut, u16 chan
>> enum lut_channel channel)
>> {
>> s64 lut_index = get_lut_index(lut, channel_value);
>> + u16 *floor_lut_value, *ceil_lut_value;
>> + u16 floor_channel_value, ceil_channel_value;
>>
>> /*
>> * This checks if `struct drm_color_lut` has any gap added by the compiler
>> @@ -130,11 +132,15 @@ static u16 apply_lut_to_channel_value(const struct vkms_color_lut *lut, u16 chan
>> */
>> static_assert(sizeof(struct drm_color_lut) == sizeof(__u16) * 4);
>>
>> - u16 *floor_lut_value = (__u16 *)&lut->base[drm_fixp2int(lut_index)];
>> - u16 *ceil_lut_value = (__u16 *)&lut->base[drm_fixp2int_ceil(lut_index)];
>> + floor_lut_value = (__u16 *)&lut->base[drm_fixp2int(lut_index)];
>> + if (drm_fixp2int(lut_index) == (lut->lut_length - 1))
>> + /* We're at the end of the LUT array, use same value for ceil and floor */
>> + ceil_lut_value = floor_lut_value;
>> + else
>> + ceil_lut_value = (__u16 *)&lut->base[drm_fixp2int_ceil(lut_index)];
>>
>> - u16 floor_channel_value = floor_lut_value[channel];
>> - u16 ceil_channel_value = ceil_lut_value[channel];
>> + floor_channel_value = floor_lut_value[channel];
>> + ceil_channel_value = ceil_lut_value[channel];
>>
>> return lerp_u16(floor_channel_value, ceil_channel_value,
>> lut_index & DRM_FIXED_DECIMAL_MASK);
>
next prev parent reply other threads:[~2023-11-06 20:48 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 [this message]
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
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=4b0fd975-a2b8-4bfa-b06b-b08f704a099b@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).