[igt-dev] [PATCH 3/3] tests/kms_writeback: support DRM_FORMAT_XRGB2101010 for writeback

[Alex Hung]

On 2023-08-17 08:15, Harry Wentland wrote:
> 
> 
> On 2023-08-17 03:50, Maxime Ripard wrote:
>> On Thu, Aug 17, 2023 at 01:09:44AM -0600, Alex Hung wrote:
>>>
>>>
>>> On 2023-08-17 00:32, Maxime Ripard wrote:
>>>> Hi,
>>>>
>>>> On Wed, Aug 16, 2023 at 02:53:16PM -0600, Alex Hung wrote:
>>>>> Allow kms_writeback to run with DRM_FORMAT_XRGB8888 if supported
>>>>> or to try DRM_FORMAT_XRGB2101010 if DRM_FORMAT_XRGB8888 is not
>>>>> available.
>>>>
>>>> XRGB8888 is always supposed to be available, if it's not, it's a driver
>>>> issue. Which means that XRGB2101010 will never actually be tested.
>>>
>>> It is up to a device driver to support specific format(s), not necessary an
>>> issue. At least for now amdgpu won't support XRGB8888 but XRGB2101010.
>>
>> I guess it's unrelated to that patch in particular, but it's not ok from
>> a KMS standpoint. It was poorly documented before, but see
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fb_helper.c#L430
>> https://lore.kernel.org/dri-devel/20230807140317.26146-2-jfalempe@redhat.com/

We are not supporting any userspace applications other than testing. I 
also don't read this as "you MUST do color conversion to 8888" but as 
"color conversion to 8888 is one of two cases you are allowed to do".

>>
> 
> Our HW writeback can't do 8888. This would be a silly reason to not be
> able to use it for testing purposes.
> 
> I don't even understand what "SW Color Conversion" means here. Is it
> expected that drivers use CPU code in kernel to walk the buffer and
> "color convert" from XRGB8888 to whatever the HW supports (and the
> inverse for the writeback buffer)? That seems a bit ridiculous.
> 
> Harry
> 
> 
>>>> I think we should make a proper test for that format, instead of a
>>>> (silent) fallback?
>>>
>>> Not sure what's the proper test or the fallback you are referring to. The
>>> intention here is to test XRGB2101010 when possible without breaking the
>>> original behaviours for XRGB8888.
>>
>> Right, but you're not even testing that XRGB2101010 is actually there,
>> so if amdgpu format listing was somehow broken and you were to expose
>> XRGB8888 instead of XRGB2101010, you wouldn't notice. That's not great.

Only XRGB2101010 is supported.

>>
>>> Changing kms_writeback to tests multiple formats requires significant
>>> modifications and tests which requires a driver capable of multiple formats
>>> in the first place.
>>
>> That's fine, amdgpu will be that driver.

The purpose of this patch is to improve kms_writeback coverage:

- check XRGB8888, and test if supported or skip otherwise
to
- no XRGB8888? also check XRGB2101010, and test if supported or skip 
otherwise

For amdgpu, no writeback -> support XRGB2101010 in writeback.

XRGB2101010 will be used for testing. XRGB8888 may or may not be added 
later depending on whether there will be consumers of the feature but 
that is out of scope of this IGT patch.

Alex

>>
>> Maxime
>