From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (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 11553386434 for ; Wed, 25 Mar 2026 18:12:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774462327; cv=pass; b=h7ZmagBsj8Z/3zcyOU8JnPlzol7wDGTe/jiFvNHSOR+lnqvyn7aTqSMiufaoO096zyIQCe7isvxPRSXIP2B7/zs4G5BxY2fxT2WnuON2zawj5EsaI1JZNiFwA6TzjoEnzBDrKVZQT/RzJV3B/rhb9snN6/4o1sU9KB2eNi7WtJ0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774462327; c=relaxed/simple; bh=Osw/eX0186WDIfEd6TaTagwe35C9BoFyATyWjD6auGI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nwYZ0JK9Ya8WfwexKXxacwzjNxOfclSFa4Dadvq3biKfLRCDySDv+/VmHkWZMZa65RL2emFiak7dPizl2lFHrBtksn2I1NMGY7b6ALSZFFTBg0K+nqkrD2GkCyeI0SLZ1XugQ2vhwHvnC9OH4KflGVPUuR/UDMbU5HgYL/5v7KU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=adrian.larumbe@collabora.com header.b=SBSGRw4/; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=adrian.larumbe@collabora.com header.b="SBSGRw4/" ARC-Seal: i=1; a=rsa-sha256; t=1774462313; cv=none; d=zohomail.com; s=zohoarc; b=KvQWx4HxrZrYYdvZSbOnixGWhlflQAmfJlqWSPAvBQisy1OmApprWPZPTIO7iJImHhOsWRc8bR8S3qOUlZAglTNTJMLDujY8Krq+tI+4z1pXz8eqsi1X1vDPBTbQjxPmzQ5VXHONLbNuufbcGshd7F4wBPqqcyBLVB2MpsiGG6M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1774462313; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=AYVxKP58Bk5grRF6I6V018P5+nFwGJxlGe+ZLG2GXvs=; b=aKqkpK80WhUioHv8oW8SSIZOXh/XEX/XLRAbRBEoRQ1YoFZ9wrF3FqplWcP2v52K7zbMnoAX9eopaGjRdycY0s3DvDLd2EXewKxGvTT4LtkQ5djB/P7N1obeoR1vUWApDZq0NwJx3jAaonF2jhHm8F3r/I3wYLIAWpFSB2DJoOU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=adrian.larumbe@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1774462313; s=zohomail; d=collabora.com; i=adrian.larumbe@collabora.com; h=Date:Date:From:From:To:To:Cc:Cc:Subject:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:Message-Id:Reply-To; bh=AYVxKP58Bk5grRF6I6V018P5+nFwGJxlGe+ZLG2GXvs=; b=SBSGRw4/hdZNYQWmSstCfVaSLc1v+kcElVbCPQ/bhQU696U4iAriSjEr/q2u9IEK 1aXzg1QnqvdVVe5RYEpwY4m1P0ZJ7HONaxzjAq3Jc6uispciOjsUmuNDaV7XPM9q3AY IqbNBReYc74QgIailZR7CVtOP6RvSczThpmNxm1g= Received: by mx.zohomail.com with SMTPS id 1774462311923736.4018108026393; Wed, 25 Mar 2026 11:11:51 -0700 (PDT) Date: Wed, 25 Mar 2026 18:11:48 +0000 From: =?utf-8?Q?Adri=C3=A1n?= Larumbe To: Dave Airlie Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Steven Price , Boris Brezillon , Janne Grunau , kernel@collabora.com Subject: Re: [PATCH v5 00/11] Support repeated mappings in GPUVM and Panthor Message-ID: References: <20260313150956.1618635-1-adrian.larumbe@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Dave, On 25.03.2026 06:51, Dave Airlie wrote: > On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe > wrote: > > > > This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO > > region over an address range repeatedly with just one map operation. > > > > Sparse resources in the Vulkan API let the user leave regions of a > > resource unmapped (from the API perspective.) Accesses to such regions > > must not result in program termination, but loads produce undefined > > values. > > > > To implement this feature on Mali hardware, Vulkan sparse unmap is > > implemented by mapping the specified region to a "dummy bo" so that the > > accesses do not fault. A newly created sparse resource starts off > > unmapped, and therefore also has to be mapped to the "dummy bo". This > > "dummy bo" is small (a page size) in comparison to the sizes of va > > ranges that we might want to map to it, and a large number of vm_bind > > ops can be necessary. For example, if the user were to create a > > 100e6-byte sparse resident resource, we'd have to poke VM_BIND with > > ceil(100e6/0x1000)=24415 map operations. > > So other drivers pass a NULL (xe) operation to their VM BIND which > then goes into the kernel and is handled in the backend to write the > special sparse PT entry. > > Can't you just do the same thing in the driver backend, have a dummy > bo allocated in the kernel and map the pages to it when you see a NULL > mapping, We could. There's been some ongoing talk among Collaborans about whether to move all this functionality into the driver backend. We decided to keep it part of the gpuvm core because we thought other drivers might profit from it, but if there's no such interest, I think it's best to leave the DRM core untouched and handle repeated mappings the way you suggested. > or does this mess up some accounting or refcounts? > > Dave. Adrian Larumbe