similar to: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

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

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 >

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

On 7/22/23 17:12, 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 implementation 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

On Mon, Jul 24, 2023 at 9:04?PM Danilo Krummrich <dakr at redhat.com> wrote: > On 7/22/23 17:12, 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 implementation for the new uapi motivated > > by the > > Vulkan

On 7/25/23 18:16, Faith Ekstrand wrote: > On Mon, Jul 24, 2023 at 9:04?PM Danilo Krummrich <dakr at redhat.com > <mailto:dakr at redhat.com>> wrote: > > On 7/22/23 17:12, Faith Ekstrand wrote: > > On Wed, Jul 19, 2023 at 7:15?PM Danilo Krummrich <dakr at redhat.com > <mailto:dakr at redhat.com> > > <mailto:dakr at redhat.com

kernel-doc emits a warning: include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand * @NOUVEAU_GETPARAM_EXEC_PUSH_MAX on line 49 - I thought it was a doc line We don't have a way to document a macro value via kernel-doc, so change the "/**" kernel-doc marker to a C comment and format the comment more like a kernel-doc comment for consistency. Fixes: d59e75eef52d

On 12/24/23 22:51, Vegard Nossum wrote: > 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' >

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

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

On 7/25/23 18:43, Danilo Krummrich wrote: > On 7/25/23 18:16, Faith Ekstrand wrote: >> Thanks for the detailed write-up! That would definitely explain it. If >> I remember, I'll try to do a single-threaded run or two. If your >> theory is correct, there should be no real perf difference when >> running single-threaded. Those runs will take a long time, though, so

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 Tue, Jul 25, 2023 at 5:48?PM Danilo Krummrich <dakr at redhat.com> wrote: > On 7/25/23 18:43, Danilo Krummrich wrote: > > On 7/25/23 18:16, Faith Ekstrand wrote: > >> Thanks for the detailed write-up! That would definitely explain it. If > >> I remember, I'll try to do a single-threaded run or two. If your > >> theory is correct, there should be no

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

On 12/25/23 00:30, Vegard Nossum wrote: > > On 25/12/2023 08:40, Randy Dunlap wrote: >> I do see one thing that I don't like in the generated html output. >> It's not a problem with this patch. >> The #defines for DRM_NOUVEAU_VM_BIND_OP_MAP etc. have a ';' at the >> end of each line: >> >> struct drm_nouveau_vm_bind_op { >> ????