search for: drm_gpuva

...;boris.brezillon at collabora.com> Suggested-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- Documentation/gpu/drm-mm.rst | 36 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem.c | 3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1743 +++++++++++++++++++++++++++++++ include/drm/drm_drv.h | 6 + include/drm/drm_gem.h | 52 + include/drm/drm_gpuva_mgr.h | 756 ++++++++++++++ 7 files changed, 2597 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 includ...

...n <donald.robson at imgtec.com> Suggested-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- Documentation/gpu/drm-mm.rst | 36 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem.c | 3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1730 +++++++++++++++++++++++++++++++ include/drm/drm_drv.h | 6 + include/drm/drm_gem.h | 79 ++ include/drm/drm_gpuva_mgr.h | 706 +++++++++++++ 7 files changed, 2561 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 includ...

...n <donald.robson at imgtec.com> Suggested-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- Documentation/gpu/drm-mm.rst | 36 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem.c | 3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1728 +++++++++++++++++++++++++++++++ include/drm/drm_drv.h | 6 + include/drm/drm_gem.h | 79 ++ include/drm/drm_gpuva_mgr.h | 706 +++++++++++++ 7 files changed, 2559 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 includ...

...eatures appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. The implementation introduces struct drm_gpuva_gem, which serves as abstraction combining a struct drm_gpuva_manager and struct drm_gem_object, similar to what amdgpu does with struct amdgpu_bo_vm. While this adds a bit of complexity it improves the efficiency of tracking evicted GEM objects. [1] provides an alternative implementation using a m...

...Signed-off-by: Danilo Krummrich <dakr at redhat.com> >>>> --- >>>> Documentation/gpu/drm-mm.rst | 31 + >>>> drivers/gpu/drm/Makefile | 1 + >>>> drivers/gpu/drm/drm_gem.c | 3 + >>>> drivers/gpu/drm/drm_gpuva_mgr.c | 1704 +++++++++++++++++++++++++++++++ >>>> include/drm/drm_drv.h | 6 + >>>> include/drm/drm_gem.h | 75 ++ >>>> include/drm/drm_gpuva_mgr.h | 714 +++++++++++++ >>>> 7 files changed, 2534 insertions(+) &g...

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

...d >>> try to write to the tree then things will go poorly.. In this scenario, >>> we are very much walking the tree and writing to it in two steps. >>> >>>> >>>> To remove an entry while walking the tree I have a separate function >>>> drm_gpuva_iter_remove(). Would I need something similar for inserting >>>> entries? >>> >>> I saw that. Your remove function uses the erase operation which is >>> implemented as a walk to that location and a store of a null over the >>> range that is returned....

...> Some quick comments since I'm doing some Xe work in this area. Will probably >>>>>> get back with more. >>>>>> >>>>>> On 8/20/23 23:53, Danilo Krummrich wrote: > <snip> > >>>>>>> diff --git a/include/drm/drm_gpuva_mgr.h b/include/drm/drm_gpuva_mgr.h >>>>>>> index ed8d50200cc3..693e2da3f425 100644 >>>>>>> --- a/include/drm/drm_gpuva_mgr.h >>>>>>> +++ b/include/drm/drm_gpuva_mgr.h >>>>>>> @@ -26,12 +26,16 @@ >>>>&gt...

...; 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 drm_gpuva_manager_ext_assert_held(mgr) \ >>> + lockdep_assert(lock_is_held((mgr)->ext_lock) != LOCK_STATE_NOT_HELD) >>> +/** >>> + * drm_gpuva_manager_set_ext_lock - set the external lock according to >>> + * @DRM_GPUVA_MANAGER_LOCK_EXTERN >>> + * @mgr: the &a...

...O offset 0). > > To make this work, we need to handle all the corner cases when these > mappings intersect with regular mappings. The rules are simply to never > mix or merge a "regular" mapping with a single page mapping. > > drm_gpuvm has support for a flags field in drm_gpuva objects. This is > normally managed by drivers directly. We can introduce a > DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > sm_map and friends need to know ahead of time whether the new mapping is > a single page mapping or not. Therefore, we need to add an argu...

...all the corner cases when these > > > > mappings intersect with regular mappings. The rules are simply to never > > > > mix or merge a "regular" mapping with a single page mapping. > > > > > > > > drm_gpuvm has support for a flags field in drm_gpuva objects. This is > > > > normally managed by drivers directly. We can introduce a > > > > DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > > > > sm_map and friends need to know ahead of time whether the new mapping is > > > > a s...

...k, we need to handle all the corner cases when these > > > mappings intersect with regular mappings. The rules are simply to never > > > mix or merge a "regular" mapping with a single page mapping. > > > > > > drm_gpuvm has support for a flags field in drm_gpuva objects. This is > > > normally managed by drivers directly. We can introduce a > > > DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > > > sm_map and friends need to know ahead of time whether the new mapping is > > > a single page mapping o...

...gt; To make this work, we need to handle all the corner cases when these > > mappings intersect with regular mappings. The rules are simply to never > > mix or merge a "regular" mapping with a single page mapping. > > > > drm_gpuvm has support for a flags field in drm_gpuva objects. This is > > normally managed by drivers directly. We can introduce a > > DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > > sm_map and friends need to know ahead of time whether the new mapping is > > a single page mapping or not. Therefore, we...

...> Signed-off-by: Danilo Krummrich <dakr at redhat.com> >>>> --- >>>> Documentation/gpu/drm-mm.rst | 31 + >>>> drivers/gpu/drm/Makefile | 1 + >>>> drivers/gpu/drm/drm_gem.c | 3 + >>>> drivers/gpu/drm/drm_gpuva_mgr.c | 1704 +++++++++++++++++++++++++++++++ >>>> include/drm/drm_drv.h | 6 + >>>> include/drm/drm_gem.h | 75 ++ >>>> include/drm/drm_gpuva_mgr.h | 714 +++++++++++++ >>>> 7 files changed, 2534 insertions(+) >&g...

...release the reference of + * + * This releases a reference to @gpuvm. + * + * This function may be called from atomic context. + */ +void +drm_gpuvm_put(struct drm_gpuvm *gpuvm) +{ + if (gpuvm) + kref_put(&gpuvm->kref, drm_gpuvm_free); +} +EXPORT_SYMBOL_GPL(drm_gpuvm_put); static int __drm_gpuva_insert(struct drm_gpuvm *gpuvm, @@ -839,11 +862,21 @@ drm_gpuva_insert(struct drm_gpuvm *gpuvm, { u64 addr = va->va.addr; u64 range = va->va.range; + int ret; if (unlikely(!drm_gpuvm_range_valid(gpuvm, addr, range))) return -EINVAL; - return __drm_gpuva_insert(gpuvm, va); + ret...

...to handle all the corner cases when these > >>> mappings intersect with regular mappings. The rules are simply to never > >>> mix or merge a "regular" mapping with a single page mapping. > >>> > >>> drm_gpuvm has support for a flags field in drm_gpuva objects. This is > >>> normally managed by drivers directly. We can introduce a > >>> DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > >>> sm_map and friends need to know ahead of time whether the new mapping is > >>> a single pa...

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 &drm_gpuva objects. It also keeps track of >> the >> + * mapping's backing &drm_gem_object buffers. >...

...t) the same relationship I introduce with the GPUVA >>> manager? >>> >>> If you would switch over to the GPUVA manager right now, it would be >>> that every GEM has a list of it's mappings (the gpuva list). The >>> mapping is represented by struct drm_gpuva (of course embedded in >>> driver specific structure(s)) which has a pointer to the VM address >>> space it is part of, namely the GPUVA manager instance. And the GPUVA >>> manager keeps a maple tree of it's mappings as well. >>> >>> If you still...

...gt; +/** > + * 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 operations: inserting, removing and iterating > + * &drm_gpuva objects as well as generating all kinds of operations, such as > + * split / merge or prefetch. > + * > + * The GPU VA manager also does not take care of the locking of the backing > + * &drm_gem_object buffers GPU VA lists by itself; drivers are responsible to > + * enforce mutu...

...>>>> 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 &drm_gpuva objects. It also keeps >>>>> track of the >>>>> + * mappi...