search for: vm_binds

On 7/22/23 00:58, Faith Ekstrand wrote: > > On Wed, Jul 19, 2023 at 7:15?PM Danilo Krummrich <dakr at redhat.com > <mailto:dakr at redhat.com>> 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 >

...ver, by comparison, is 33us/exec so it's not syncobj overhead. This > is a bit concerning (you'd think the new thing would be faster) but what > really has me concerned is the 1k buffer case. > > If you include the top patch in the crucible MR, it allocates 1000 BOs > and VM_BINDs them. All the binding is done before the warmup EXEC. > Suddenly, the submit time jumps to 257 us/exec with the new UAPI. The > old UAPI is much worse (1134 us/exec) but that's not the point. Once > we've done the first EXEC and created our VM bindings, the cost per EXEC > s...

...s 33us/exec so it's not syncobj overhead. This > > is a bit concerning (you'd think the new thing would be faster) but what > > really has me concerned is the 1k buffer case. > > > > If you include the top patch in the crucible MR, it allocates 1000 BOs > > and VM_BINDs them. All the binding is done before the warmup EXEC. > > Suddenly, the submit time jumps to 257 us/exec with the new UAPI. The > > old UAPI is much worse (1134 us/exec) but that's not the point. Once > > we've done the first EXEC and created our VM bindings, the cost per...

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

...This > > is a bit concerning (you'd think the new thing would be faster) > but what > > really has me concerned is the 1k buffer case. > > > > If you include the top patch in the crucible MR, it allocates > 1000 BOs > > and VM_BINDs them. All the binding is done before the warmup EXEC. > > Suddenly, the submit time jumps to 257 us/exec with the new UAPI. > The > > old UAPI is much worse (1134 us/exec) but that's not the point. Once > > we've done the first EXEC and created our VM...

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

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

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

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

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

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

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

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

From: Dave Airlie <airlied at redhat.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

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

From: Dave Airlie <airlied at redhat.com> dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below. op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000 This

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