search for: 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...

...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 11/9/23 17:03, Christian K?nig wrote: > Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >> [SNIP] >>>> >> Did we get any resolution on this? >> >> FWIW, my take on this is that it would be possible to get GPUVM to work both with and without internal refcounting; If with, the driver needs a vm close to resolve cyclic references, if without that's not necessary. If GPUVM is allowed to refcount in mappings and vm_bos, that comes with a slight performance drop but as Danilo pointed out, the VM lifetime pr...

...chrieb Danilo Krummrich: > On 11/9/23 17:03, Christian K?nig wrote: >> Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >>> [SNIP] >>>>> >>> Did we get any resolution on this? >>> >>> FWIW, my take on this is that it would be possible to get GPUVM to >>> work both with and without internal refcounting; If with, the driver >>> needs a vm close to resolve cyclic references, if without that's not >>> necessary. If GPUVM is allowed to refcount in mappings and vm_bos, >>> that comes with a slight perfor...

...;> On 11/9/23 17:03, Christian K?nig wrote: >>> Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >>>> [SNIP] >>>>>> >>>> Did we get any resolution on this? >>>> >>>> FWIW, my take on this is that it would be possible to get GPUVM to >>>> work both with and without internal refcounting; If with, the >>>> driver needs a vm close to resolve cyclic references, if without >>>> that's not necessary. If GPUVM is allowed to refcount in mappings >>>> and vm_bos, that comes with...

...>>>>> mm_struct is destroyed. >>>> >>>> Certainly, that would be possible. However, thinking about it, this >>>> might call for >>>> huge trouble. >>>> >>>> First of all, we'd still need to reference count a GPUVM and take a >>>> reference for each >>>> VM_BO, as we do already. Now instead of simply increasing the >>>> reference count for each >>>> mapping as well, we'd need a *mandatory* driver callback that is >>>> called when the GPUVM &gt...

...tically destroyed when the mm_struct is >>>> destroyed. >>> >>> Certainly, that would be possible. However, thinking about it, this >>> might call for >>> huge trouble. >>> >>> First of all, we'd still need to reference count a GPUVM and take a >>> reference for each >>> VM_BO, as we do already. Now instead of simply increasing the >>> reference count for each >>> mapping as well, we'd need a *mandatory* driver callback that is >>> called when the GPUVM >>> reference...

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...

On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote: > On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew <achew at nvidia.com> wrote: > > Hello, > > > > I am currently looking into ways to support fixed virtual address allocations > > and sparse mappings in nouveau, as a step towards supporting CUDA. > > > > CUDA requires that the GPU virtual address

...etest: allocate and commit atomic request around set_property() Neil Armstrong (2): modetest: permit -r and -s to work together modetest: allow using -r and -P Rohith Iyer (1): modetest: add support for writeback connector Samuel Pitoiset (2): amdgpu: amdgpu_drm.h for new GPUVM fault ioctl amdgpu: add support for querying VM faults information Simon Ser (3): xf86drm: mark DRM_MAX_MINOR as deprecated ci: bump FreeBSD to 13.2 build: bump version to 2.4.117 git tag: libdrm-2.4.117 https://dri.freedesktop.org/libdrm/libdrm-2.4.117.tar.xz SHA256: a28...