search for: dma_resv

Am 27.08.23 um 19:54 schrieb Dmitry Osipenko: > Add simple kref_put_dma_resv() helper that wraps around kref_put_ww_mutex() > for drivers that needs to lock dma-resv on kref_put(). > > It's not possible to easily add this helper to kref.h because of the > headers inclusion dependency, hence add it to dma-resv.h. I was never really a big fan of kref_put_mute...

Am 10.10.23 um 22:23 schrieb Dave Airlie: >> I think we're then optimizing for different scenarios. Our compute >> driver will use mostly external objects only, and if shared, I don't >> forsee them bound to many VMs. What saves us currently here is that in >> compute mode we only really traverse the extobj list after a preempt >> fence wait, or when a vm is

On Wed, 11 Oct 2023 at 17:07, Christian K?nig <christian.koenig at amd.com> wrote: > > Am 10.10.23 um 22:23 schrieb Dave Airlie: > >> I think we're then optimizing for different scenarios. Our compute > >> driver will use mostly external objects only, and if shared, I don't > >> forsee them bound to many VMs. What saves us currently here is that in

Am 12.10.23 um 12:33 schrieb Dave Airlie: > On Wed, 11 Oct 2023 at 17:07, Christian K?nig <christian.koenig at amd.com> wrote: >> Am 10.10.23 um 22:23 schrieb Dave Airlie: >>>> I think we're then optimizing for different scenarios. Our compute >>>> driver will use mostly external objects only, and if shared, I don't >>>> forsee them bound

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ben Skeggs <bskeggs at...

...ernally to pass the GPU VMs >>>>>>> + * dma-resv to &drm_exec. >>>>>>> + */ >>>>>>> + struct drm_gem_object d_obj; >>>>>>> + >>>>>>> + /** >>>>>>> + * @resv: the &dma_resv for &drm_gem_objects mapped in this GPU VA >>>>>>> + * space >>>>>>> + */ >>>>>>> + struct dma_resv *resv; >>>>>>> + >>>>>>> + /** >>>>>>> + * @exec: the &drm_exe...

...ux/list.h> >>>>>>> +#include <linux/mutex.h> >>>>>>> ? #include <drm/drm_vma_manager.h> >>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object { >>>>>>> ?????? */ >>>>>>> ????? struct dma_resv _resv; >>>>>>> +??? /** >>>>>>> +???? * @gpuva: >>>>>>> +???? * >>>>>>> +???? * Provides the list of GPU VAs attached to this GEM object. >>>>>>> +???? * >>>>>>> +???? * Dri...

...t;>>>>>> +#include <linux/mutex.h> >>>>>>>> ? #include <drm/drm_vma_manager.h> >>>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object { >>>>>>>> ?????? */ >>>>>>>> ????? struct dma_resv _resv; >>>>>>>> +??? /** >>>>>>>> +???? * @gpuva: >>>>>>>> +???? * >>>>>>>> +???? * Provides the list of GPU VAs attached to this GEM object. >>>>>>>> +???? * >>>>>...

...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 mutual exclusion using either the GEMs dma_resv lock or alternatively > + * a driver specific external lock by setting the @DRM_GPUVA_MANAGER_LOCK_EXTERN > + * flag. > + * > + * For the latter, functions such as drm_gpuva_link() or drm_gpuva_unlink() > + * contain lockdep checks to indicate locking issues. For this to work drivers...

...her VM. > ?2. Any attempt to export an INTERNAL BO via prime or a similar > mechanism will fail with -EINVAL (I think?). > > Inside the kernel driver, all the internal BOs on a VM (or DRM file in > the case of nouveau/AMD since they don't have VM objects) share a single > dma_resv which allows you to avoid having to walk lists of BOs and take > locks on every exec. Instead, you can just look at the fences on the > dma_resv for the VM. There's still a BO list associated with the VM for > external BOs but, in most Vulkan applications, there are less than a &gt...

...ut this particular locking hell > because if we hold I have to agree with Danilo here. Especially you have cases where you usually lock BO->VM (for example eviction) as well as cases where you need to lock VM->BO (command submission). Because of this in amdgpu we used (or abused?) the dma_resv of the root BO as lock for the VM. Since this is a ww_mutex locking it in both VM, BO as well as BO, VM order works. Regards, Christian. > , for example a vm and bo resv when putting the vm_bo, we need to keep > additional strong references for the bo / vm pointer we use for > unlock...

...> hell because if we hold > > I have to agree with Danilo here. Especially you have cases where you > usually lock BO->VM (for example eviction) as well as cases where you > need to lock VM->BO (command submission). > > Because of this in amdgpu we used (or abused?) the dma_resv of the > root BO as lock for the VM. Since this is a ww_mutex locking it in > both VM, BO as well as BO, VM order works. Yes, gpuvm is doing the same. (although not necessarily using the page-table root bo, but any bo of the driver's choice). But I read it as Danilo feared the case w...

...e, u32 flags, - u32 tile_mode, u32 tile_flags); +struct nouveau_bo *nouveau_bo_alloc(struct nouveau_cli *, u64 *size, int *align, + u32 flags, u32 tile_mode, u32 tile_flags); int nouveau_bo_init(struct nouveau_bo *, u64 size, int align, u32 flags, struct sg_table *sg, struct dma_resv *robj); int nouveau_bo_new(struct nouveau_cli *, u64 size, int align, u32 flags, diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index c2bfc0591909..1bdffd714456 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem...

...attempt to export an INTERNAL BO via prime or a similar > > mechanism will fail with -EINVAL (I think?). > > > > Inside the kernel driver, all the internal BOs on a VM (or DRM file in > > the case of nouveau/AMD since they don't have VM objects) share a single > > dma_resv which allows you to avoid having to walk lists of BOs and take > > locks on every exec. Instead, you can just look at the fences on the > > dma_resv for the VM. There's still a BO list associated with the VM for > > external BOs but, in most Vulkan applications, there are less...

On Wed, Aug 21, 2019 at 11:50:29PM +0200, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by > pushing the writeback of the new presumed offsets to the very end. > > Aside from "it compiles" entirely untested unfortunately. > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.co...

...rev_va, ctx->next_va, &op->remap); >> + * >> + * drm_gpuva_unlink(op->remap.unmap->va); >> + * kfree(op->remap.unmap->va); >> + * >> + * if (op->remap.prev) { >> + * drm_gpuva_link(ctx->prev_va); > > I ended up switching to dma_resv-based locking for the GEMs and I > wonder what the locking is supposed to look like in the async-mapping > case, where we insert/remove the VA nodes in the drm_sched::run_job() > path. If you decide to pick the interface where you just call drm_gpuva_sm_[un]map() and receive a callback f...

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ilia Mirkin <imirkin a...

...el/-/commit/2a7e1b0ece2c3bba43376783b577d97ae6f6e54f [2] https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/gpuva-vm-resv [3] https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/gpuva-vm-resv-vm-bo Danilo Krummrich (3): drm: drm_exec: build always builtin drm/gpuva_mgr: generalize dma_resv/extobj handling and GEM validation drm/nouveau: gpuva mgr dma-resv/extobj handling, GEM validation drivers/gpu/drm/Kconfig | 6 - drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_gpuva_mgr.c | 688 +++++++++++++++++++++++- drivers/gpu/drm/nouveau/K...

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are fixes for a couple of issues that I've been running into when testing on various Tegra boards. The first two patches fix up issues in the fix that I had sent out earlier to fix the regression introduced in drm-misc-next. The first one is critical because it avoids a BUG_ON as reported by Ilia, while the second is less

...at we can proceed under the assumption that there are no more serious perf issues with the new API. I'm happy to RB/ACK the next version of the API and implementation patches, as long as it has the new NO_SHARE BO create flag and properly rejects exports of NO_SHARE BOs, even if not all of the dma_resv plumbing is fully baked. ~Faith -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20230730/80238903/attachment.htm>