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

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 >

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

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

Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For

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

Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For

On Tue, Aug 22, 2023 at 6:41?PM Danilo Krummrich <dakr at redhat.com> wrote: > Currently, NO_PREFETCH is passed implicitly through > drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. > > Since this is a direct representation of how the HW is programmed it > isn't really future proof for a uAPI. Hence, fix this up for the new > uAPI and split up

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