From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2045.outbound.protection.outlook.com [40.107.223.45]) by gabe.freedesktop.org (Postfix) with ESMTPS id 94B0810E4A5 for ; Thu, 17 Aug 2023 14:15:12 +0000 (UTC) Message-ID: <28f80f34-c7a9-44c8-a33a-6ded92458e29@amd.com> Date: Thu, 17 Aug 2023 10:15:04 -0400 Content-Language: en-US To: Maxime Ripard , Alex Hung References: <20230816205316.867195-1-alex.hung@amd.com> <20230816205316.867195-3-alex.hung@amd.com> <5zt2ctyod27qaw7sld4ejvvemgxm6chh4dtf7cnjiil2rizksm@bfiezcb3zo3q> <5cd3fc34-f6c7-21ff-f710-cb3f543fcb80@amd.com> From: Harry Wentland In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: Re: [igt-dev] [PATCH 3/3] tests/kms_writeback: support DRM_FORMAT_XRGB2101010 for writeback List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: igt-dev@lists.freedesktop.org, brian.starkey@arm.com Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" List-ID: 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