[PATCH i-g-t] tests/kms_color: Enable ctm-limited-range subtest

[Sharma, Swati2]

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 at 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.
>
> 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+.
So, is there anything we can do to fix this test to enable it back or 
let it be in disabled
state only?
>