search for: drm_gpuvas

...typical application drivers would embed struct drm_gpuva_manager and + * struct drm_gpuva within their own driver specific structures, there won't be + * any memory allocations of it's own nor memory allocations of &drm_gpuva + * entries. + * + * The data structures needed to store &drm_gpuvas within the &drm_gpuva_manager + * are contained within struct drm_gpuva already. Hence, for inserting + * &drm_gpuva entries from within dma-fence signalling critical sections it is + * enough to pre-allocate the &drm_gpuva structures. + */ + +/** + * DOC: Split and Merge + * + * Beside...

...In a typical application drivers would embed struct drm_gpuva_manager and + * struct drm_gpuva within their own driver specific structures, there won't be + * any memory allocations of its own nor memory allocations of &drm_gpuva + * entries. + * + * The data structures needed to store &drm_gpuvas within the &drm_gpuva_manager + * are contained within struct drm_gpuva already. Hence, for inserting + * &drm_gpuva entries from within dma-fence signalling critical sections it is + * enough to pre-allocate the &drm_gpuva structures. + */ + +/** + * DOC: Split and Merge + * + * Beside...

...In a typical application drivers would embed struct drm_gpuva_manager and + * struct drm_gpuva within their own driver specific structures, there won't be + * any memory allocations of its own nor memory allocations of &drm_gpuva + * entries. + * + * The data structures needed to store &drm_gpuvas within the &drm_gpuva_manager + * are contained within struct drm_gpuva already. Hence, for inserting + * &drm_gpuva entries from within dma-fence signalling critical sections it is + * enough to pre-allocate the &drm_gpuva structures. + */ + +/** + * DOC: Split and Merge + * + * Beside...

So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM

...XPORT_SYMBOL(drm_gpuva_remove); >>>> + >>> ... >>> >>>> +/** >>>> + * drm_gpuva_find_first - find the first &drm_gpuva in the given range >>>> + * @mgr: the &drm_gpuva_manager to search in >>>> + * @addr: the &drm_gpuvas address >>>> + * @range: the &drm_gpuvas range >>>> + * >>>> + * Returns: the first &drm_gpuva within the given range >>>> + */ >>>> +struct drm_gpuva * >>>> +drm_gpuva_find_first(struct drm_gpuva_manager *mgr, >>...

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 >> + * @start__: starting offset, the first gpuva will overlap this >> + * @end__: ending offset, the last gpuva will start before this (but may >...

...+ >>>>> ... >>>>> >>>>>> +/** >>>>>> + * drm_gpuva_find_first - find the first &drm_gpuva in the given range >>>>>> + * @mgr: the &drm_gpuva_manager to search in >>>>>> + * @addr: the &drm_gpuvas address >>>>>> + * @range: the &drm_gpuvas range >>>>>> + * >>>>>> + * Returns: the first &drm_gpuva within the given range >>>>>> + */ >>>>>> +struct drm_gpuva * >>>>>> +drm_gpuva_fi...

...as list entry >>>>> instead, which also seems to be the obvious choice. However, there is a locking >>>>> conflict. >>>>> >>>>> A drm_gem_object keeps a list of drm_gpuva_gems, while each drm_gpuva_gem keeps >>>>> a list of drm_gpuvas. Both lists are either protected with the dma-resv lock of >>>>> the corresponding drm_gem_object, or with an external lock provided by the >>>>> driver (see drm_gem_gpuva_set_lock()). The latter is used by drivers performing >>>>> changes on the GPUVA s...

...gt;>> + * @mgr: the &drm_gpuva_manager to set the lock for >>> + * @lock: the lock to set >>> + * >>> + * If @DRM_GPUVA_MANAGER_LOCK_EXTERN is set, drivers need to call this function >>> + * to provide the lock used to lock linking and unlinking of &drm_gpuvas to the >>> + * &drm_gem_objects GPUVA list. >>> + */ >>> +#define drm_gpuva_manager_set_ext_lock(mgr, lock) \ >>> + (mgr)->ext_lock = &(lock)->dep_map >> >> Okay, so, IIUC, this is the lock protecting the GEM's active mappings >&g...

On 2/28/23 17:24, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230227 21:17]: >> On Tue, Feb 21, 2023 at 01:20:50PM -0500, Liam R. Howlett wrote: >>> * Danilo Krummrich <dakr at redhat.com> [230217 08:45]: >>>> Add infrastructure to keep track of GPU virtual address (VA) mappings >>>> with a decicated VA space manager

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

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

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:

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

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

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

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

...ANAGER_LOCK_EXTERN >> + * @mgr: the &drm_gpuva_manager to set the lock for >> + * @lock: the lock to set >> + * >> + * If @DRM_GPUVA_MANAGER_LOCK_EXTERN is set, drivers need to call this function >> + * to provide the lock used to lock linking and unlinking of &drm_gpuvas to the >> + * &drm_gem_objects GPUVA list. >> + */ >> +#define drm_gpuva_manager_set_ext_lock(mgr, lock) \ >> + (mgr)->ext_lock = &(lock)->dep_map >> +#else >> +typedef struct { /* nothing */ } lockdep_map_p; > > lockdep_map_p conflicts with...

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

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