search for: gpuvas

...l do that in a driver specific way. >>>> >>>> Do I miss something? >>> >>> How do you efficiently find only the mappings of a BO in one VM? >> >> Actually, I think this case should even be more efficient than with a >> BO having a list of GPUVAs (or mappings): > > *than with a BO having a list of VMs: > >> >> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. >> Hence, you'd only need to iterate the list of mappings for a given BO >> and check the mappings VM pointer. Yeah, and...

...ic way. >>>>> >>>>> Do I miss something? >>>> >>>> How do you efficiently find only the mappings of a BO in one VM? >>> >>> Actually, I think this case should even be more efficient than with a >>> BO having a list of GPUVAs (or mappings): >> >> *than with a BO having a list of VMs: >> >>> >>> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. >>> Hence, you'd only need to iterate the list of mappings for a given BO >>> and check the map...

...gt; per GEM, you could still do that in a driver specific way. >>> >>> Do I miss something? >> >> How do you efficiently find only the mappings of a BO in one VM? > > Actually, I think this case should even be more efficient than with a BO > having a list of GPUVAs (or mappings): *than with a BO having a list of VMs: > > Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. > Hence, you'd only need to iterate the list of mappings for a given BO > and check the mappings VM pointer. > > Having a list of VMs per BO...

...llocations >>>> (drm_mm based) and a different component/interface for tracking the >>>> VA mappings (probably rb tree based). >>> >>> That's what the GPUVA manager is doing. There are gpuva_regions >>> which correspond to VA allocations and gpuvas which represent the >>> mappings. Both are tracked separately (currently both with a >>> separate drm_mm, though). However, the GPUVA manager needs to take >>> regions into account when dealing with mappings to make sure the >>> GPUVA manager doesn't prop...

...a different component/interface for tracking >>>>>>> the VA mappings (probably rb tree based). >>>>>> >>>>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>>>> which correspond to VA allocations and gpuvas which represent the >>>>>> mappings. Both are tracked separately (currently both with a >>>>>> separate drm_mm, though). However, the GPUVA manager needs to >>>>>> take regions into account when dealing with mappings to make sure >>&gt...

...>>> (drm_mm based) and a different component/interface for tracking the >>>>> VA mappings (probably rb tree based). >>>> >>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>> which correspond to VA allocations and gpuvas which represent the >>>> mappings. Both are tracked separately (currently both with a >>>> separate drm_mm, though). However, the GPUVA manager needs to take >>>> regions into account when dealing with mappings to make sure the >>>> GPUVA manager...

Hi Oded, sorry for the late response, somehow this mail slipped through. On 2/6/23 15:48, Oded Gabbay wrote: > On Thu, Jan 19, 2023 at 7:24 AM Matthew Brost <matthew.brost at intel.com> wrote: >> Is this not an application issue? Millions of mappings seems a bit >> absurd to me. > If I look at the most extreme case for AI, assuming 256GB of HBM > memory and page

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

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

...t;>> (drm_mm based) and a different component/interface for tracking the > >>>> VA mappings (probably rb tree based). > >>> > >>> That's what the GPUVA manager is doing. There are gpuva_regions > >>> which correspond to VA allocations and gpuvas which represent the > >>> mappings. Both are tracked separately (currently both with a > >>> separate drm_mm, though). However, the GPUVA manager needs to take > >>> regions into account when dealing with mappings to make sure the > >>> GPUVA manager...

Am 27.01.23 um 02:26 schrieb Danilo Krummrich: > On 1/27/23 02:05, Matthew Brost wrote: >> On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >>> This commit provides the interfaces for the new UAPI motivated by the >>> Vulkan API. It allows user mode drivers (UMDs) to: >>> >>> 1) Initialize a GPU virtual address (VA) space via the new

On 20/07/2023 01:14, Danilo Krummrich wrote: > 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

...us binds/unbinds through the job scheduler is a concern I think it could be beneficial to (pre-)allocate page tables for newly requested mappings without the need to know whether there are existing mappings within this range already (ideally without tracking page table allocations separate from GPUVAs), such that we can update the VA space at job execution time. Same thing for freeing page tables for a range that only partially contains mappings at all. For that, reference counting page tables per mapping wouldn't really work. On the other hand we need to consider that freeing page tabl...

Hi Boris, On 3/9/23 10:48, Boris Brezillon wrote: > On Thu, 9 Mar 2023 10:12:43 +0100 > Boris Brezillon <boris.brezillon at collabora.com> wrote: > >> Hi Danilo, >> >> On Fri, 17 Feb 2023 14:44:06 +0100 >> Danilo Krummrich <dakr at redhat.com> wrote: >> >>> Changes in V2: >>> ============== >>> Nouveau: >>>

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

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

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

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

On 1/27/23 02:05, Matthew Brost wrote: > On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >> This commit provides the interfaces for the new UAPI motivated by the >> Vulkan API. It allows user mode drivers (UMDs) to: >> >> 1) Initialize a GPU virtual address (VA) space via the new >> DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel

On 1/27/23 04:21, Matthew Brost wrote: > On Fri, Jan 27, 2023 at 02:43:30AM +0100, Danilo Krummrich wrote: >> >> >> On 1/27/23 02:05, Matthew Brost wrote: >>> On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >>>> This commit provides the interfaces for the new UAPI motivated by the >>>> Vulkan API. It allows user mode drivers