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

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

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

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

+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 mappings

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

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