search for: drm_gpuvm

Implement reference counting for struct drm_gpuvm. Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/drm_gpuvm.c | 56 +++++++++++++++++++++----- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 ++++++--- include/drm/drm_gpuvm.h | 31 +++++++++++++- 3 files changed, 90 insertions(+), 17 deletion...

+Akash with whom we've been discussing adding a 'REPEAT' mode to drm_gpuvm/panthor. On Sun, 2 Feb 2025 19:53:47 +0100 Danilo Krummrich <dakr at kernel.org> wrote: > Hi Lina, > > On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote: > > Some hardware requires dummy page mappings to efficiently implement > > Vulkan sparse features. These...

...025 at 10:34:49PM +0900, Asahi Lina wrote: > Some hardware requires dummy page mappings to efficiently implement > Vulkan sparse features. These mappings consist of the same physical > memory page, repeated for a large range of address space (e.g. 16GiB). > > Add support for this to drm_gpuvm. Currently, drm_gpuvm expects BO > ranges to correspond 1:1 to virtual memory ranges that are mapped, and > does math on the BO offset accordingly. To make single page mappings > work, we need a way to turn off that math, keeping the BO offset always > constant and pointing to the same...

On Mon, Feb 03, 2025 at 10:21:53AM +0100, Boris Brezillon wrote: > +Akash with whom we've been discussing adding a 'REPEAT' mode to > drm_gpuvm/panthor. > > On Sun, 2 Feb 2025 19:53:47 +0100 > Danilo Krummrich <dakr at kernel.org> wrote: > > > Hi Lina, > > > > On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote: > > > Some hardware requires dummy page mappings to efficiently implement...

On Mon, 3 Feb 2025 11:23:53 +0000 Liviu Dudau <liviu.dudau at arm.com> wrote: > On Mon, Feb 03, 2025 at 10:21:53AM +0100, Boris Brezillon wrote: > > +Akash with whom we've been discussing adding a 'REPEAT' mode to > > drm_gpuvm/panthor. > > > > On Sun, 2 Feb 2025 19:53:47 +0100 > > Danilo Krummrich <dakr at kernel.org> wrote: > > > > > Hi Lina, > > > > > > On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote: > > > > Some hardware requires d...

On Mon, 3 Feb 2025 22:46:15 +0900 Asahi Lina <lina at asahilina.net> wrote: > Hi, > > On 2/3/25 6:21 PM, Boris Brezillon wrote: > > +Akash with whom we've been discussing adding a 'REPEAT' mode to > > drm_gpuvm/panthor. > > > > On Sun, 2 Feb 2025 19:53:47 +0100 > > Danilo Krummrich <dakr at kernel.org> wrote: > > > >> Hi Lina, > >> > >> On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote: > >>> Some hardware requires dummy p...

...port a >>> destructor for the base-class, rather than to have the base-class >>> provide the refcount and a destructor? ops. > > GPUVM simply follows the same pattern we have with drm_gem_objects. > And I think it makes > sense. Why would we want to embed two struct drm_gpuvm in a single > driver structure? Because you need one drm_gpuvm structure for each application using the driver? Or am I missing something? As far as I can see a driver would want to embed that into your fpriv structure which is allocated during drm_driver.open callback. > >> >&...

...9;s subclass provide get() and put() ops, and export a destructor for the base-class, rather than to have the base-class provide the refcount and a destructor? ops. GPUVM simply follows the same pattern we have with drm_gem_objects. And I think it makes sense. Why would we want to embed two struct drm_gpuvm in a single driver structure? > > Well, I have never seen stuff like that in the kernel. Might be that this works, but I would rather not try if avoidable. > >> >> That would also make it possible for the driver to decide the context for the put() call: If the driver needs t...

...destructor for the base-class, rather than to have the base-class >>>> provide the refcount and a destructor? ops. >> >> GPUVM simply follows the same pattern we have with drm_gem_objects. >> And I think it makes >> sense. Why would we want to embed two struct drm_gpuvm in a single >> driver structure? > > Because you need one drm_gpuvm structure for each application using > the driver? Or am I missing something? > > As far as I can see a driver would want to embed that into your fpriv > structure which is allocated during drm_driver.ope...

...n >> drm_gem_object_funcs.close. >> >> Since it is perfectly legal for userspace to close a BO while there >> are still mappings (can trivial be that the app is killed) I would >> expect that the drm_gem_object_funcs.close handling is something like >> asking drm_gpuvm destroying the VM_BO and getting the mappings which >> should be cleared in the page table in return. >> >> In amdgpu we even go a step further and the VM structure keeps track >> of all the mappings of deleted VM_BOs so that higher level can query >> those and clea...

...object_funcs.close. >>> >>> Since it is perfectly legal for userspace to close a BO while there >>> are still mappings (can trivial be that the app is killed) I would >>> expect that the drm_gem_object_funcs.close handling is something >>> like asking drm_gpuvm destroying the VM_BO and getting the mappings >>> which should be cleared in the page table in return. >>> >>> In amdgpu we even go a step further and the VM structure keeps track >>> of all the mappings of deleted VM_BOs so that higher level can query >&gt...

...DRM: MM: using COPY for buffer copies ------------[ cut here ]------------ nouveau 0000:01:00.0: drm_WARN_ON(!found_head) WARNING: CPU: 4 PID: 786 at drivers/gpu/drm/nouveau/dispnv50/disp.c:2731 nv50_display_init+0x28c/0x4f0 [nouveau] Modules linked in: nouveau(+) drm_ttm_helper ttm video drm_exec drm_gpuvm gpu_sched drm_display_helper wmi CPU: 4 PID: 786 Comm: systemd-udevd Not tainted 6.6.0+ #1 Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7599/870-C45 (MS-7599), BIOS V1.15 03/04/2011 RIP: 0010:nv50_display_init+0x28c/0x4f0 [nouveau] Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 6d 47 37 e1 48 c...