search for: drm_exec

...gt;>>>> +#include <linux/maple_tree.h> >>>>>>> #include <linux/rbtree.h> >>>>>>> #include <linux/types.h> >>>>>>> #include <drm/drm_gem.h> >>>>>>> +#include <drm/drm_exec.h> >>>>>>> struct drm_gpuva_manager; >>>>>>> +struct drm_gpuva_gem; >>>>>>> struct drm_gpuva_fn_ops; >>>>>>> /** >>>>>>> @@ -140,7 +144,7 @@ struct drm_gpuva { >>>>...

...series. [1] https://gitlab.freedesktop.org/nouvelles/kernel/-/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...

...osed to be taken outside the VM context and the locking order > is always the same (VM lock first, and then each shared BO > taken/released independently), but I'm not super thrilled by this > nested lock, and I'm wondering if we shouldn't have a pass collecting > locks in a drm_exec context first, and then have > the operations executed. IOW, something like that: > > drm_exec_init(exec, DRM_EXEC_IGNORE_DUPLICATES) > drm_exec_until_all_locked(exec) { > // Dummy GEM is the dummy GEM object I use to make the VM > // participate in the locking without havi...

....brost at intel.com> > > > Tested-by: Donald Robson <donald.robson at imgtec.com> > > > Suggested-by: Dave Airlie <airlied at redhat.com> > > > Signed-off-by: Danilo Krummrich <dakr at redhat.com> > > > > For some reason this breaks the drm_exec kunit patches: > > Fix available here [1]. > > [1]https://lore.kernel.org/dri-devel/cbf4ccf9-8131-27a0-332c-6942866340d1 at igalia.com/T/#t Thanks for pointing it out :) Maxime -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: ap...

...:01:00.0: DRM: MM: using COPY for buffer copies ------------[ cut here ]------------ nouveau 0000:01:00.0: drm_WARN_ON(!found_head) WARNING: CPU: 4 PID: 786 at drivers/gpu/drm/nouveau/dispnv50/disp.c:2731 nv50_display_init+0x28c/0x4f0 [nouveau] Modules linked in: nouveau(+) drm_ttm_helper ttm video drm_exec drm_gpuvm gpu_sched drm_display_helper wmi CPU: 4 PID: 786 Comm: systemd-udevd Not tainted 6.6.0+ #1 Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7599/870-C45 (MS-7599), BIOS V1.15 03/04/2011 RIP: 0010:nv50_display_init+0x28c/0x4f0 [nouveau] Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 6d 47...

...with the DRM GPU VA manager. > > 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The > ? ?execution happens asynchronously. It supports DRM syncobj (incl. > ? ?timelines) as synchronization mechanism. DRM GEM object locking is > ? ?handled with drm_exec. > > Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM > GPU scheduler for the asynchronous paths. > > > IDK where the best place to talk about this is but this seems as good as > any. > > I've been looking into why the Vulkan CTS ru...

...> > > 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. > The > > execution happens asynchronously. It supports DRM syncobj (incl. > > timelines) as synchronization mechanism. DRM GEM object locking > is > > handled with drm_exec. > > > > Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the > DRM > > GPU scheduler for the asynchronous paths. > > > > > > IDK where the best place to talk about this is but this seems as good as > > any. > > > > I...

...ush buffers with the new DRM_IOCTL_NOUVEAU_EXEC > ioctl. The > >? ? ? ? ?execution happens asynchronously. It supports DRM syncobj > (incl. > >? ? ? ? ?timelines) as synchronization mechanism. DRM GEM object > locking is > >? ? ? ? ?handled with drm_exec. > > > >? ? ?Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, > use the DRM > >? ? ?GPU scheduler for the asynchronous paths. > > > > > > IDK where the best place to talk about this is but this seems as > goo...

...m_gpuva_op to create a new mapping:: + * + * // Allocates a new &drm_gpuva. + * struct drm_gpuva * driver_gpuva_alloc(void); + * + * // Typically drivers would embedd the &drm_gpuva_manager and &drm_gpuva + * // structure in individual driver structures and lock the dma-resv with + * // drm_exec or similar helpers. + * int driver_mapping_create(struct drm_gpuva_manager *mgr, + * u64 addr, u64 range, + * struct drm_gem_object *obj, u64 offset) + * { + * struct drm_gpuva_ops *ops; + * struct drm_gpuva_op *op + * + * driver_lock_va_space(); + * ops = drm_gpuva_sm_map_ops_create(...

...m_gpuva_op to create a new mapping:: + * + * // Allocates a new &drm_gpuva. + * struct drm_gpuva * driver_gpuva_alloc(void); + * + * // Typically drivers would embedd the &drm_gpuva_manager and &drm_gpuva + * // structure in individual driver structures and lock the dma-resv with + * // drm_exec or similar helpers. + * int driver_mapping_create(struct drm_gpuva_manager *mgr, + * u64 addr, u64 range, + * struct drm_gem_object *obj, u64 offset) + * { + * struct drm_gpuva_ops *ops; + * struct drm_gpuva_op *op + * + * driver_lock_va_space(); + * ops = drm_gpuva_sm_map_ops_create(...

...m_gpuva_op to create a new mapping:: + * + * // Allocates a new &drm_gpuva. + * struct drm_gpuva * driver_gpuva_alloc(void); + * + * // Typically drivers would embedd the &drm_gpuva_manager and &drm_gpuva + * // structure in individual driver structures and lock the dma-resv with + * // drm_exec or similar helpers. + * int driver_mapping_create(struct drm_gpuva_manager *mgr, + * u64 addr, u64 range, + * struct drm_gem_object *obj, u64 offset) + * { + * struct drm_gpuva_ops *ops; + * struct drm_gpuva_op *op + * + * driver_lock_va_space(); + * ops = drm_gpuva_sm_map_ops_create(...