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

[Harry Wentland]

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/
> 

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.
> 
>> 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.
> 
> Maxime