From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AC3D256C90 for ; Tue, 11 Mar 2025 12:46:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741697215; cv=none; b=lp5/KFS29Qu6t7GaCGoF5YmUTbrNu4InqBeAb45r+h+mcevT1dSiLwM5LWNxleoX4ASb0uPRikWCgCIKvcR4pXmZjFRJAULOSBtJMhWt1mHHGrS+CoJXC8xEDolekp+E4lEk724CvQKm6Wa+DKtqFM+0CXBpEgPoI8G7wEbaE+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741697215; c=relaxed/simple; bh=hIuzAPv8x7HdhF3kOYgKUE08BcmIV4Tk3xoim98ixEQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sqqkZfVjqTndpTn8cBTz/vbpW0hG9mf+vqrnrfAQxdcFOtNQ2SRoraa8g7afnjgJqHJDM+4FnDSVG6S/2x5YFzUWTA4E2Kt/YCONs84ITETYo/RXQ3k9tQIPzY0QIB+EtoYvzGgQhv8/uAUBGjipOtFPSacM7YmwT5qCuzNF3rk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=rosenzweig.io; spf=pass smtp.mailfrom=rosenzweig.io; dkim=pass (2048-bit key) header.d=rosenzweig.io header.i=@rosenzweig.io header.b=iOqEUJgv; arc=none smtp.client-ip=95.215.58.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=rosenzweig.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rosenzweig.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rosenzweig.io header.i=@rosenzweig.io header.b="iOqEUJgv" Date: Tue, 11 Mar 2025 08:46:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rosenzweig.io; s=key1; t=1741697201; 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: in-reply-to:in-reply-to:references:references; bh=mOG0CEw3FP2FlG0epn5X7Xw21NWLyIUELyR5vBonHPk=; b=iOqEUJgvADrMU0rIWuG0Ruc7Rtt8IZl+4o95HtRzhUdZyQGFZ1JqrK6ZYGRItGhaB/i6vx SUKlcXNM56cjtmk6uLgcFTxRSu13CBv7gM8RK/UHtKCdvpIuuoCKgOg2ZyE5WaPzY26G76 uyHRVJJ+1DwdlUYaed7Wflte4dOcoRNxcMzYlo6FIlE42eXoaGrJVauc3xcB5jmYo5XCcD BUXc+bXEclIcJh9ZSiUkawPEsyTzJaoUtop39EGchJ3EqbnbnlWjQvuj3E3YGsIrgGFuaL uZv6bDGFaxw6XdeG2kdrdBdFkuQ7+IJDK/zThbDQLqxqGNj8xUbEJQw7INmUrA== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alyssa Rosenzweig To: Rob Clark Cc: David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Faith Ekstrand , Janne Grunau , Sven Peter , Jonathan Corbet , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, Asahi Lina Subject: Re: [PATCH] drm: Add UAPI for the Asahi driver Message-ID: References: <20250310-agx-uapi-v1-1-86c80905004e@rosenzweig.io> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT > > +/** > > + * struct drm_asahi_gem_bind - Arguments passed to > > + * DRM_IOCTL_ASAHI_GEM_BIND > > + */ > > +struct drm_asahi_gem_bind { > > + /** @op: Bind operation (enum drm_asahi_bind_op) */ > > + __u32 op; > > + > > + /** @flags: One or more of ASAHI_BIND_* (BIND only) */ > > + __u32 flags; > > + > > + /** @handle: GEM object to bind/unbind (BIND or UNBIND_ALL) */ > > + __u32 handle; > > + > > + /** @vm_id: The ID of the VM to operate on */ > > + __u32 vm_id; > > + > > + /** @offset: Offset into the object (BIND only) */ > > + __u64 offset; > > + > > + /** > > + * @range: Number of bytes to bind/unbind to addr (BIND or UNBIND only) > > + */ > > + __u64 range; > > + > > + /** @addr: Address to bind to (BIND or UNBIND only) */ > > + __u64 addr; > > +}; > > No in/out syncobj/fences? This seems to diverge from xe/nouveau/panthor.. Async vm_bind is useful mainly as an optimization, it's not (as far as I know) required for correctness - you can always wait/signal from a userspace submit thread with sync vm_bind. It's my understanding (from when I chatted with Faith about this when bringing up sparse) that this is how sparse was implemented historically and maybe still is on Windows? > > +/** > > + * enum drm_asahi_sync_type - Sync item type > > + */ > > +enum drm_asahi_sync_type { > > + /** @DRM_ASAHI_SYNC_SYNCOBJ: Binary sync object */ > > + DRM_ASAHI_SYNC_SYNCOBJ = 0, > > + > > + /** @DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ: Timeline sync object */ > > + DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ = 1, > > +}; > > IMHO it would still be worthwhile to also support fence fd's, since it > would avoid a couple extra ioctls to convert btwn fence fds and > syncobj for virtgpu native context.. Ditto for this as an optimization. Both of these can be added in a straightforward backwards-compat way later, so I'm inclined to not add any extra functionality beyond what we already have (and know works), rather than commit prematurely to new features and risk getting something wrong. (and then it means more rust bindings...)