similar to: [PATCH drm-misc-next 0/3] [RFC] DRM GPUVA Manager GPU-VM features

Hi, On 8/31/23 13:18, Danilo Krummrich wrote: > On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellstr?m (Intel) wrote: >> Hi! >> >> On 8/30/23 17:00, Danilo Krummrich wrote: >>> On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellstr?m (Intel) wrote: >>>> On 8/30/23 14:49, Danilo Krummrich wrote: >>>>> Hi Thomas, >>>>>

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

On 2/22/23 11:25, Christian K?nig wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: <snip> >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by

Am 22.06.23 um 17:07 schrieb Danilo Krummrich: > On 6/22/23 17:04, Danilo Krummrich wrote: >> On 6/22/23 16:42, Christian K?nig wrote: >>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>>> On 6/22/23 15:54, Christian K?nig wrote: >>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich: >>>>>> Hi Christian, >>>>>>

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 deletions(-) diff --git a/drivers/gpu/drm/drm_gpuvm.c

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

This commit adds a function to dump a DRM GPU VA space and a macro for drivers to register the struct drm_info_list 'gpuvas' entry. Most likely, most drivers might maintain one DRM GPU VA space per struct drm_file, but there might also be drivers not having a fixed relation between DRM GPU VA spaces and a DRM core infrastructure, hence we need the indirection via the driver iterating

On 6/23/23 09:16, Christian K?nig wrote: > Am 22.06.23 um 17:07 schrieb Danilo Krummrich: >> On 6/22/23 17:04, Danilo Krummrich wrote: >>> On 6/22/23 16:42, Christian K?nig wrote: >>>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>>>> On 6/22/23 15:54, Christian K?nig wrote: >>>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

From: Dave Airlie <airlied at redhat.com> dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below. op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000 This

Am 22.02.23 um 17:40 schrieb Danilo Krummrich: > On 2/22/23 16:14, Christian K?nig wrote: >> Am 22.02.23 um 16:07 schrieb Danilo Krummrich: >>> On 2/22/23 11:25, Christian K?nig wrote: >>>> Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >>> >>> <snip> >>> >>>>> +/** >>>>> + * DOC: Overview

On 6/22/23 17:04, Danilo Krummrich wrote: > On 6/22/23 16:42, Christian K?nig wrote: >> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>> On 6/22/23 15:54, Christian K?nig wrote: >>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich: >>>>> Hi Christian, >>>>> >>>>> On 6/20/23 08:45, Christian K?nig wrote:

Am 09.11.23 um 19:34 schrieb 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

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

On 7/7/23 09:57, Boris Brezillon wrote: > On Thu, 6 Jul 2023 20:26:42 +0200 > Boris Brezillon <boris.brezillon at collabora.com> wrote: > >> On Fri, 30 Jun 2023 00:25:18 +0200 >> Danilo Krummrich <dakr at redhat.com> wrote: >> >>> +#ifdef CONFIG_LOCKDEP >>> +typedef struct lockdep_map *lockdep_map_p; >>> +#define

On 7/7/23 13:00, Boris Brezillon wrote: > On Fri, 30 Jun 2023 00:25:18 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > >> +/** >> + * drm_gpuva_for_each_va_range - iternator to walk over a range of &drm_gpuvas >> + * @va__: &drm_gpuva structure to assign to in each iteration step >> + * @mgr__: &drm_gpuva_manager to walk over >> + *

On 11/10/23 09:50, Christian K?nig wrote: > Am 09.11.23 um 19:34 schrieb 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

Hi Danilo, The below part of the documentation is out of date now. Thanks, Donald On Thu, 2023-07-13 at 19:03 +0200, Danilo Krummrich wrote: > > + > +/** > + * DOC: Locking > + * > + * Generally, the GPU VA manager does not take care of locking itself, it is > + * the drivers responsibility to take care about locking. Drivers might want to > + * protect the following

From: Dave Airlie <airlied at redhat.com> When a buffer is evicted for memory pressure or TTM evict all, the placement is set to the eviction domain, this means the buffer never gets revalidated on the next exec to the correct domain. I think this should be fine to use the initial domain from the object creation, as least with VM_BIND this won't change after init so this should be the

On 3/2/23 03:38, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230227 08:17]: > > ... >>>> Would this variant be significantly more efficient? >>> >>> Well, what you are doing is walking the tree to see if there's anything >>> there... then re-walking the tree to store it. So, yes, it's much more >>>