Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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+.
>>>


  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