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 B1256EC1E92 for ; Thu, 5 Feb 2026 10:46:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D288F10E866; Thu, 5 Feb 2026 10:46:48 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="rUPqsLIb"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 72B5E10E863; Thu, 5 Feb 2026 10:46:47 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4FF7C43D66; Thu, 5 Feb 2026 10:46:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69962C16AAE; Thu, 5 Feb 2026 10:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770288407; bh=lvjwOZpBeoLfOCmz0qi802CU+ZXxa8qVWxRNbI2stqo=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=rUPqsLIb+b/uRA0s0Xp5sV2UXcgZhox6Na7ZzRK15oB2jygIkiC4rCHgmCRWqcj/6 9g/mO6SSHIhg/DE3XxIvbBQciNymgx7dJHfL25zOYpr3GmMa58LNE9BtuqMQxaif52 U6jNLQh10MXNsgGZDwpavwVa3wWOpYgLQMGgg6yzmGNreEA+u5wDn5FFDuaNsYk1Kd bz+PLGc5pRvSc/YMcdIpb3+9v0KQvnpIKXZ6W07WuYtZgMeby2WNAXgIne2X9ycB9C Jjb8Jwdfha2lkmn3qmR+G7NtMld/cw4X6eoPyeSG7nuyO/H0XLF1pBqHtTfxsfYTBE hfDdI2Ii3NZcQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 05 Feb 2026 11:46:43 +0100 Message-Id: Subject: Re: [PATCH 1/2] drm/nouveau: Add DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO Cc: "M Henning" , "Karol Herbst" , "Lyude Paul" , , , "Faith Ekstrand" , , To: "Dave Airlie" From: "Danilo Krummrich" References: <20250312213746.228042-1-mhenning@darkrefraction.com> <20250312213746.228042-2-mhenning@darkrefraction.com> In-Reply-To: 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 Thu Feb 5, 2026 at 2:16 AM CET, Dave Airlie wrote: > On Fri, 28 Mar 2025 at 21:09, Danilo Krummrich wrote: >> >> (CC: Ben, John) >> >> On Thu, Mar 27, 2025 at 02:03:21PM -0400, M Henning wrote: >> > On Thu, Mar 27, 2025 at 9:51=E2=80=AFAM Danilo Krummrich wrote: >> > > >> > > On Fri, Mar 21, 2025 at 06:06:34PM -0400, M Henning wrote: >> > > > On Thu, Mar 20, 2025 at 2:18=E2=80=AFPM Danilo Krummrich wrote: >> > > > > On Wed, Mar 12, 2025 at 05:36:14PM -0400, Mel Henning wrote: >> > > > > > + __u32 width_align_pixels; >> > > > > > + __u32 height_align_pixels; >> > > > > > + __u32 pixel_squares_by_aliquots; >> > > > > > + __u32 aliquot_total; >> > > > > > + __u32 zcull_region_byte_multiplier; >> > > > > > + __u32 zcull_region_header_size; >> > > > > > + __u32 zcull_subregion_header_size; >> > > > > > + __u32 subregion_count; >> > > > > > + __u32 subregion_width_align_pixels; >> > > > > > + __u32 subregion_height_align_pixels; >> > > > > > + >> > > > > > + __u32 ctxsw_size; >> > > > > > + __u32 ctxsw_align; >> > > > > > +}; >> > > > > >> > > > > What if this ever changes between hardware revisions or firmware= versions? >> > > > >> > > > There was some previous discussion of that here: >> > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12596#note_27968= 53 >> > > > >> > > > From what I can tell, this structure hasn't really changed since >> > > > FERMI_C (circa 2011), so I'm not too worried about it changing on = us >> > > > too quickly. When it does change, we have the option of appending = more >> > > > members to this struct in the usual way, or if the change is more >> > > > fundamental we can return an error from this ioctl and add a new >> > > > interface. Userspace needs to handle an error from this ioctl >> > > > gracefully anyway since whether it works or not depends on the gpu >> > > > generation and what firmware is loaded right now. >> > > >> > > We could also define it as >> > > >> > > struct drm_nouveau_get_zcull_info { >> > > __u32 version; >> > > __u32 _pad; >> > > >> > > union { >> > > struct drm_nouveau_get_zcull_info_v1 info; >> > > } >> > > } >> > > >> > > just to be safe. >> > >> > We can do that, although I don't see any other drm drivers using a >> > similar pattern anywhere. >> >> I think it's a bit cleaner than adding new members, leave existing ones = unset or >> add a new IOCTL in the worst case. >> >> Maybe the NVIDIA folks can give us some hint on whether this is expected= to >> change at some point? > > I think it's an ioctl, let's just leave out version/pad, adding a new > ioctl isn't a major trouble if the world decides we need to do it. > > Also you can extend ioctls with new fields at the end without > problems, so if it's just extra info it'll likely be hw specific and > be part of enabling a new GPU. Yeah, that's why I said "it's a bit cleaner than adding new members, leave existing ones unset or add a new IOCTL in the worst case" above. :) Anyways, this is quite a while ago and things have changed. I think we can afford to be a bit less future proof in terms of new GPU (and firmware) sup= port. :)