From: "Sharma, Swati2" <swati2.sharma@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t] tests/kms_color: Enable ctm-limited-range subtest
Date: Tue, 25 Mar 2025 11:31:29 +0530 [thread overview]
Message-ID: <2e9ff80e-b7f3-44c0-8d37-fcdbe85d6b68@intel.com> (raw)
In-Reply-To: <Z9QqZTuTZKiK_4CJ@intel.com>
Hi Ville,
On 14-03-2025 06:38 pm, Ville Syrjälä wrote:
> On Fri, Mar 14, 2025 at 06:04:07PM +0530, Sharma, Swati2 wrote:
>> Hi Ville,
>>
>> On 15-02-2025 02:34 am, Ville Syrjälä wrote:
>>> On Fri, Feb 14, 2025 at 11:56:27PM +0530, Sharma, Swati2 wrote:
>>>> Hi Ville,
>>>>
>>>> On 14-02-2025 11:00 pm, Ville Syrjälä wrote:
>>>>> On Fri, Feb 14, 2025 at 09:40:11PM +0530, Swati Sharma wrote:
>>>>>> This tests is currently disabled since CRC computed on Intel
>>>>>> hardware seems to include data on the lower bits, this is
>>>>>> preventing us to CRC checks.
>>>>>>
>>>>>> Let's try to enable it back and check behavior on newer Intel
>>>>>> platforms.
>>>>>>
>>>>>> Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
>>>>>> ---
>>>>>> tests/kms_color.c | 166 ++++++++++++++++++++++++++--------------------
>>>>>> 1 file changed, 93 insertions(+), 73 deletions(-)
>>>>>>
>>>>>> diff --git a/tests/kms_color.c b/tests/kms_color.c
>>>>>> index 4b71d3dd3..c3b285b4e 100644
>>>>>> --- a/tests/kms_color.c
>>>>>> +++ b/tests/kms_color.c
>>>>>> @@ -58,6 +58,7 @@
>>>>>> * @0-75: for 0.75 transparency
>>>>>> * @blue-to-red: from blue to red
>>>>>> * @green-to-red: from green to red
>>>>>> + * @limited-range: with identity matrix
>>>>>> * @max: for maximum transparency
>>>>>> * @negative: for negative transparency
>>>>>> * @red-to-blue: from red to blue
>>>>>> @@ -623,107 +624,97 @@ static bool test_pipe_ctm(data_t *data,
>>>>>> * This test is currently disabled as the CRC computed on Intel hardware seems
>>>>>> * to include data on the lower bits, this is preventing us to CRC checks.
>>>>>> */
>>>>>> -#if 0
>>>>>> -static void test_pipe_limited_range_ctm(data_t *data,
>>>>>> +static bool test_pipe_limited_range_ctm(data_t *data,
>>>>>> igt_plane_t *primary)
>>>>>> {
>>>>>> double limited_result = 235.0 / 255.0;
>>>>>> - static const color_t red_green_blue_limited[] = {
>>>>>> + color_t red_green_blue_limited[] = {
>>>>>> { limited_result, 0.0, 0.0 },
>>>>>> { 0.0, limited_result, 0.0 },
>>>>>> - { 0.0, 0.0, limited_result },
>>>>>> + { 0.0, 0.0, limited_result }
>>>>>> };
>>>>> This whole thing is fundementally broken. We can't generate
>>>>> limited range output without using the CSC post offsets,
>>>>> which are not exposed via the current CTM uapi.
>>>> We do have its equivalent test in kms_color_chamelium
>>>> and it seems its passing
>>>> https://gfx-ci.igk.intel.com/cibuglog-ng/results/all?query_key=af49bc8e4e7d1c69ce04f9a1196c167456e8344a
>>>> Is it wrong?
>>> Hmm. Looks like the test has nothing really to do with the
>>> CTM (despite the name), and instead if just uses identity CTM
>>> and puts the limited range equivalent data directly into the
>>> fb. So I guess technically it could sort of work.
>>>
>>> For the chamelium version the port will chop off the extra
>>> low bits so I guess that explains why it works.
>> I recently dumped port images of this test on chamelium. Since this test
>> is consistently passing on BMG; however failing on PTL.
>>
>> What i observed is
>>
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-A-DP-1-capture-ece4-ece4-ece4-ece4.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-A-DP-1-reference-0000-0000-0000-0000.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-B-DP-1-capture-ece4-ece4-ece4-ece4.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-B-DP-1-reference-0000-0000-0000-0000.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-C-DP-1-capture-ece4-ece4-ece4-ece4.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-C-DP-1-reference-0000-0000-0000-0000.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-D-DP-1-capture-ece4-ece4-ece4-ece4.png
>> /tmp/frame-kms_chamelium_color-ctm-limited-range-pipe-D-DP-1-reference-0000-0000-0000-0000.png
>>
>> CRC of reference and captured images are not same. Ref is all black. But
>> still test is passing :/
>> Is test broken even for chamelium?
> Looks like it:
> 1. creates a bunch of all black fbs
> 2. manually draw limited range equivalent content into one fb
> 3. set the output to full range
> 4. commit
> 5. redraw the same fb with full range contnet
> 6. set the output to limited range
> 7 *no* commit
> 6. capture the frame and compare against the all black fbref
>
> So looks completely broken to me, and I don't see how that could
> be passing on anything unless the chamelium frame comparison code
> itself is broken.
Tried fixing the test. Can you please review
https://patchwork.freedesktop.org/series/146647/
With these frame dumps match however CRC differs as expected.
>
>>> The crc version is more tricky:
>>> - g4x presuambly won't work because the port color range
>>> bit won't affect the pipe crc
>>> - ilk-ivb/vlv/chv won't work because TRANSCONF_COLOR_RANGE_SELECT
>>> doesn't seem to affect the pipe crc either
>>> - icl+ uses the output csc for the limited range conversion
>>> so the gamma LUT lsb chopping doesn't do anything, so we may
>>> get some differences in the low bits
>>> - hsw-glk maybe could work if we do enable CTM+gamma since then
>>> we'll end up doing the limited range adjustment on the gamma LUT
>>> and thus it can chop off the low bits. If we didn't enable
>>> both CTM and gamma then the limited range conversion would be
>>> done on the pipe CSC and thus it would behave exactly like icl+.
>>>
next prev parent reply other threads:[~2025-03-25 6:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 16:10 [PATCH i-g-t] tests/kms_color: Enable ctm-limited-range subtest Swati Sharma
2025-02-14 17:30 ` Ville Syrjälä
2025-02-14 18:26 ` Sharma, Swati2
2025-02-14 21:04 ` Ville Syrjälä
2025-02-18 7:23 ` Sharma, Swati2
2025-03-14 12:34 ` Sharma, Swati2
2025-03-14 13:08 ` Ville Syrjälä
2025-03-25 6:01 ` Sharma, Swati2 [this message]
2025-02-14 22:18 ` ✓ i915.CI.BAT: success for tests/kms_color: Enable ctm-limited-range subtest (rev2) Patchwork
2025-02-14 22:50 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-15 0:49 ` ✓ i915.CI.Full: " Patchwork
2025-02-16 0:02 ` ✗ Xe.CI.Full: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2025-02-14 13:00 [PATCH i-g-t] tests/kms_color: Enable ctm-limited-range subtest Swati Sharma
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=2e9ff80e-b7f3-44c0-8d37-fcdbe85d6b68@intel.com \
--to=swati2.sharma@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--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