search for: drm_nouveau_gem_pushbuf

This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to specify the tiling options of a PRIME-imported buffer. The staging parameter will allow us

...++++++++++++++++++++++++++++++++++------------ 3 files changed, 121 insertions(+), 34 deletions(-) diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h index cb077821c43f..e7f1a2aefd22 100644 --- a/include/drm/nouveau_drm.h +++ b/include/drm/nouveau_drm.h @@ -178,6 +178,28 @@ struct drm_nouveau_gem_pushbuf { __u64 gart_available; }; +#define NOUVEAU_GEM_PUSHBUF_FENCE_WAIT (1 << 0) +#define NOUVEAU_GEM_PUSHBUF_FENCE_EMIT (1 << 1) +#define NOUVEAU_GEM_PUSHBUF_FLAGS (NOUVEAU_GEM_PUSHBUF_FENCE_WAIT | \ + NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) + +struct drm_nouv...

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

...a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -482,12 +482,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, static int validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, - uint64_t user_pbbo_ptr) + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) { struct nouveau_drm *drm = chan->drm; - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = - (void __force __user *)(uintptr_t)user_pbbo_ptr; struct nouveau_bo *nvbo; int...

...uct nouveau_pushbuf *push, struct nouveau_object *chan) struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(push); struct nouveau_pushbuf_krec *krec = nvpb->list; struct nouveau_device *dev = push->client->device; + struct nouveau_drm *drm = nouveau_drm(&dev->object); struct drm_nouveau_gem_pushbuf_bo_presumed *info; struct drm_nouveau_gem_pushbuf_bo *kref; struct drm_nouveau_gem_pushbuf req; @@ -345,7 +346,7 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan) pushbuf_dump(krec, krec_id++, fifo->channel); #ifndef SIMULATE - ret = drmCommandWriteRead(dev...

...a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, static int validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, - uint64_t user_pbbo_ptr) + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) { struct nouveau_drm *drm = chan->drm; - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = - (void __force __user *)(uintptr_t)user_pbbo_ptr; struct nouveau_bo *nvbo; int...

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

...a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, static int validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, - uint64_t user_pbbo_ptr) + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) { struct nouveau_drm *drm = chan->drm; - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = - (void __force __user *)(uintptr_t)user_pbbo_ptr; struct nouveau_bo *nvbo; int...

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

...a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -482,12 +482,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, static int validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, - uint64_t user_pbbo_ptr) + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) { struct nouveau_drm *drm = chan->drm; - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = - (void __force __user *)(uintptr_t)user_pbbo_ptr; struct nouveau_bo *nvbo; int...

...eau_gem.c > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c > @@ -482,12 +482,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, > > static int > validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, > - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, > - uint64_t user_pbbo_ptr) > + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) > { > struct nouveau_drm *drm = chan->drm; > - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = > - (void __force __user *)(uintptr_t)user_pbbo_ptr; &gt...

...eau_gem.c > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c > @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, > > static int > validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli, > - struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo, > - uint64_t user_pbbo_ptr) > + struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo) > { > struct nouveau_drm *drm = chan->drm; > - struct drm_nouveau_gem_pushbuf_bo __user *upbbo = > - (void __force __user *)(uintptr_t)user_pbbo_ptr; &gt...

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

...->info.domain, req->info.tile_mode, - req->info.tile_flags, &nvbo); + req->info.bo_flags, &nvbo); if (ret) return ret; @@ -303,12 +318,14 @@ validate_fini_no_ticket(struct validate_op *op, struct nouveau_fence *fence, { struct nouveau_bo *nvbo; struct drm_nouveau_gem_pushbuf_bo *b; + bool explicit_sync; while (!list_empty(&op->list)) { nvbo = list_entry(op->list.next, struct nouveau_bo, entry); b = &pbbo[nvbo->pbbo_index]; + explicit_sync = !!(nvbo->bo_flags & NOUVEAU_GEM_EXPLICIT_SYNC); - if (likely(fence)) + if (likely(fence) &a...

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

...erved for staging, unstable ioctls */ > +#define DRM_NOUVEAU_STAGING_IOCTL 0x58 > > #define DRM_IOCTL_NOUVEAU_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new) > #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUF DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf) > #define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP DRM_IOW (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep) > #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_...

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

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 the va_len field of struct drm_nouveau_exec_push, > such that we kee...

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

...0x08 >> #define DRM_NOUVEAU_SVM_BIND 0x09 >> +#define DRM_NOUVEAU_VM_INIT 0x10 >> +#define DRM_NOUVEAU_VM_BIND 0x11 >> +#define DRM_NOUVEAU_EXEC 0x12 >> #define DRM_NOUVEAU_GEM_NEW 0x40 >> #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 >> #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 >> @@ -197,6 +410,9 @@ struct drm_nouveau_svm_bind { >> #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini) >> #define DRM_IOCTL_N...