search for: vm_bind

...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 reserved > ? ?VA area. > > 2) Bind and unbind GPU VA space mappings via the new > ? ?DRM_IOCTL_NOUVEAU_VM_BIND ioctl. > > 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. > > Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support > asynchronous processing with DRM syncobjs as synchronization mechanism. > > The default DRM_IOCTL_NOUVEAU_VM...

...RM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion > of VA > ? ?space managed by the kernel and userspace, respectively. > > 2) Allocate and free a VA space region as well as bind and unbind memory > ? ?to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. > ? ?UMDs can request the named operations to be processed either > ? ?synchronously or asynchronously. It supports DRM syncobjs > ? ?(incl. timelines) as synchronization mechanism. The management > of the > ? ?GPU VA mappings is implemented with the DR...

...l for UMDs to specify the portion > > of VA > > space managed by the kernel and userspace, respectively. > > > > 2) Allocate and free a VA space region as well as bind and unbind > memory > > to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. > > UMDs can request the named operations to be processed either > > synchronously or asynchronously. It supports DRM syncobjs > > (incl. timelines) as synchronization mechanism. The management > > of the > > GPU VA mappings i...

...ialize a GPU virtual address (VA) space via the new >>>> DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved >>>> VA area. >>>> >>>> 2) Bind and unbind GPU VA space mappings via the new >>>> DRM_IOCTL_NOUVEAU_VM_BIND ioctl. >>>> >>>> 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. >>>> >>>> Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support >>>> asynchronous processing with DRM syncobjs as synchronization mechanism. &...

...>? ? ?of VA > >? ? ? ? ?space managed by the kernel and userspace, respectively. > > > >? ? ?2) Allocate and free a VA space region as well as bind and > unbind memory > >? ? ? ? ?to the GPUs VA space via the new > DRM_IOCTL_NOUVEAU_VM_BIND ioctl. > >? ? ? ? ?UMDs can request the named operations to be processed either > >? ? ? ? ?synchronously or asynchronously. It supports DRM syncobjs > >? ? ? ? ?(incl. timelines) as synchronization mechanism. The > management > >? ? ?of the >...

...n 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: >>> - Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence >>> signalling critical sections. Updates to the VA space are split up in three >>> separate stages, where only the 2. stage executes in a fence signalling >>> critical section: >>> >>>...

On Thu, May 9, 2024 at 3:44?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found here: > https://gitlab.freedesktop.org/mesa/mesa/-/mer...

On Wed, May 8, 2024 at 6:06?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found here: > https://gitlab.freedesktop.org/mesa/mesa/-/mer...

...rivers (UMDs) to: >> >> 1) Initialize a GPU virtual address (VA) space via the new >> DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved >> VA area. >> >> 2) Bind and unbind GPU VA space mappings via the new >> DRM_IOCTL_NOUVEAU_VM_BIND ioctl. >> >> 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. >> >> Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support >> asynchronous processing with DRM syncobjs as synchronization mechanism. >> >> The default DRM_IOCTL_N...

...t; >>> 1) Initialize a GPU virtual address (VA) space via the new >>> ??? DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved >>> ??? VA area. >>> >>> 2) Bind and unbind GPU VA space mappings via the new >>> ??? DRM_IOCTL_NOUVEAU_VM_BIND ioctl. >>> >>> 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. >>> >>> Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support >>> asynchronous processing with DRM syncobjs as synchronization mechanism. >>> >>...

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

...if we can find a way to >> reduce the cross-process drag in the implementation but that's a perf >> optimization we can do later. > > From the kernel side I think the only thing we could really do is to > temporarily run a secondary drm_gpu_scheduler instance, one for VM_BINDs > and one for EXECs until we got the new page table handling in place. > > However, the UMD could avoid such conditions more effectively, since it > controls the address space. Namely, avoid re-using the same region of > the address space right away in certain cases. For instanc...

...to > >> reduce the cross-process drag in the implementation but that's a perf > >> optimization we can do later. > > > > From the kernel side I think the only thing we could really do is to > > temporarily run a secondary drm_gpu_scheduler instance, one for VM_BINDs > > and one for EXECs until we got the new page table handling in place. > > > > However, the UMD could avoid such conditions more effectively, since it > > controls the address space. Namely, avoid re-using the same region of > > the address space right away in certa...

...hat we can check for the corresponding pointer to be NULL in the particular *_fini() functions. It makes sense to allocate struct nouveau_sched separately anyway, since in a subsequent commit we can also avoid to allocate a struct nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the VM_BIND uAPI has been disabled due to the legacy uAPI being used. Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Reported-by: Timur Tabi <ttabi at nvidia.com> Closes: https://lore.kernel.org/nouveau/20240131213917.1545604-1-ttabi at nvidia.com/ Signed-of...

On 3/10/23 18:25, Boris Brezillon wrote: > Hi Danilo, > > On Fri, 10 Mar 2023 17:45:58 +0100 > Danilo Krummrich <dakr at redhat.com> wrote: >> Hi Boris, >> >>> On Thu, 9 Mar 2023 10:12:43 +0100 >>> Boris Brezillon <boris.brezillon at collabora.com> wrote: >>> >>> Ok, so I just noticed you only have one bind queue per drm_file

On Sat, Jan 28, 2023 at 1:17 AM Christian K?nig <christian.koenig at amd.com> wrote: > > Am 27.01.23 um 15:44 schrieb Danilo Krummrich: > > [SNIP] > >>>> > >>>> What you want is one component for tracking the VA allocations > >>>> (drm_mm based) and a different component/interface for tracking the > >>>> VA mappings

...at.com> When a buffer is evicted for memory pressure or TTM evict all, the placement is set to the eviction domain, this means the buffer never gets revalidated on the next exec to the correct domain. I think this should be fine to use the initial domain from the object creation, as least with VM_BIND this won't change after init so this should be the correct answer. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Cc: Danilo Krummrich <dakr at redhat.com> Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1...

As of commit b77fdd6a48e6 ("scripts/kernel-doc: restore warning for Excess struct/union"), we see the following warnings when running 'make htmldocs': ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 'DRM_NOUVEAU_VM_BIND_OP_MAP' description in 'drm_nouveau_vm_bind_op' ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 'DRM_NOUVEAU_VM_BIND_OP_UNMAP' description in 'drm_nouveau_vm_bind_op' ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 'DRM_NOU...

...operation from 0x3fffed0000+0xf0000, 0x100000 which was corrupting the pagetables and oopsing the kernel. Fixes the prev + unmap range calcs to use start/end and map back to addr/range. Signed-off-by: Dave Airlie <airlied at redhat.com> Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Cc: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c b/drivers/gpu/drm/nouveau/nouveau_uvmm.c index 9675ef25b16d..87bce1a9d073 100644 -...

On 1/27/23 16:17, Christian K?nig wrote: > Am 27.01.23 um 15:44 schrieb Danilo Krummrich: >> [SNIP] >>>>> >>>>> What you want is one component for tracking the VA allocations >>>>> (drm_mm based) and a different component/interface for tracking the >>>>> VA mappings (probably rb tree based). >>>> >>>>