From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CF58E7717F for ; Tue, 17 Dec 2024 10:13:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C280310E8E2; Tue, 17 Dec 2024 10:13:11 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; secure) header.d=mailbox.org header.i=@mailbox.org header.b="acKvEdxj"; dkim-atps=neutral Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4791510E8E2; Tue, 17 Dec 2024 10:13:10 +0000 (UTC) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4YCCLV6lBzz9sbY; Tue, 17 Dec 2024 11:13:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1734430387; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hUVNxwfgQJCoN3dSGcvl+uo7z+d2Vz7cow5BBGaB6fc=; b=acKvEdxj7cWhOTo5up4r6gLWjR0Ldq0cxSciLY1nc/vaZAO54tYBM8Rcr2wewc2v7lS1DT hrj/UQJ2XVOVYYNSptEdHgsQzD3DfCATd9NY5CUPDqduZjCQU3i7kD1GgZHKwtR2+ZrHgf 2w/agIkxuGVcTiRadFOasYEtB/QFBSZk/1jQNm15oD948LrARMoqGla8xPHv3SG/KVv4bc mZG0msCSHePq9drkSyHkxlfjbJWfgbHgQd+t0fVbm3ZMNUBNHZT0syFCt+jU7Vi3RZ71rn qIU7u5SiV442llIL4tENgfr9CoUpZ4lloSsdU9WRTKCUAJUlibzPG+R5cg1L1w== Message-ID: Date: Tue, 17 Dec 2024 11:13:05 +0100 MIME-Version: 1.0 Subject: Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment To: Brian Starkey , =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Cc: dri-devel , amd-gfx mailing list , ML Mesa-dev , nd@arm.com References: From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: de-CH-frami, en-CA In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: 3a1f9ec3600d935dfba X-MBO-RS-META: nw3u89grh81ycibjir8zm5fr4ft994fr X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2024-12-17 10:14, Brian Starkey wrote: > On Sun, Dec 15, 2024 at 03:53:14PM +0000, Marek Olšák wrote: >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR. >> >> Signed-off-by: Marek Olšák >> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >> index 78abd819fd62e..8ec4163429014 100644 >> --- a/include/uapi/drm/drm_fourcc.h >> +++ b/include/uapi/drm/drm_fourcc.h >> @@ -484,9 +484,27 @@ extern "C" { >> * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 >> ioctl), >> * which tells the driver to also take driver-internal information into >> account >> * and so might actually result in a tiled framebuffer. >> + * >> + * WARNING: >> + * There are drivers out there that expose DRM_FORMAT_MOD_LINEAR, but only >> + * support a certain pitch alignment and can't import images with this >> modifier >> + * if the pitch alignment isn't exactly the one supported. They can however >> + * allocate images with this modifier and other drivers can import them >> only >> + * if they support the same pitch alignment. Thus, DRM_FORMAT_MOD_LINEAR is >> + * fundamentically incompatible across devices and is the only modifier >> that >> + * has a chance of not working. The PITCH_ALIGN modifiers should be used >> + * instead. >> */ >> #define DRM_FORMAT_MOD_LINEAR fourcc_mod_code(NONE, 0) >> >> +/* Linear layout modifiers with an explicit pitch alignment in bytes. >> + * Exposing this modifier requires that the pitch alignment is exactly >> + * the number in the definition. >> + */ >> +#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_64B fourcc_mod_code(NONE, 1) > > Why do we want this to be a modifier? All (?) of the other modifiers > describe properties which the producer and consumer need to know in > order to correctly fill/interpret the data. > > Framebuffers already have a pitch property which tells the > producer/consumer how to do that for linear buffers. At this point, the entity which allocates a linear buffer on device A to be shared with another device B can't know the pitch restrictions of B. If it guesses incorrectly, accessing the buffer with B won't work, so any effort allocating the buffer and producing its contents will be wasted. > Modifiers are meant to describe framebuffers, and this pitch alignment > requirement isn't really a framebuffer property - it's a device > constraint. It feels out of place to overload modifiers with it. > > I'm not saying we don't need a way to describe constraints to > allocators, but I question if modifiers the right mechanism to > communicate them? While I agree with your concern in general, AFAIK there's no other solution for this even on the horizon, after years of talking about it. The solution proposed here seems like an acceptable stop gap, assuming it won't result in a gazillion linear modifiers. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast