search for: nr_push

...does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf side - there are 512 allocated IB entries (and it needs to be round number), so we can accept at most 511 entries from userspace (we need one for FIRE_RING) - fortunately userspace already flushes at 511, so nr_push check change won't have any impact Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dma.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 ++-- 3 files changed, 4 insertions(+),...

...<< 1) +#define NOUVEAU_GEM_PUSHBUF_FLAGS (NOUVEAU_GEM_PUSHBUF_FENCE_WAIT | \ + NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) + +struct drm_nouveau_gem_pushbuf2 { + uint32_t channel; + uint32_t nr_buffers; + uint64_t buffers; + uint32_t nr_relocs; + uint32_t nr_push; + uint64_t relocs; + uint64_t push; + uint32_t suffix0; + uint32_t suffix1; + uint64_t vram_available; + uint64_t gart_available; + uint32_t flags; + int32_t fence; + uint64_t reserved; +}; + #define NOUVEAU_GEM_CPU_PREP_NOWAIT 0x0000000...

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

Reduces object size ~4kb Joe Perches (2): drm/nouveau: Add new logging function nv_cli_printk drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_<level> macros drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++---- drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +++++++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 44

...veau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index f39360870c70..c0b10d8d3d03 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -856,9 +856,11 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, for (i = 0; i < req->nr_push; i++) { struct nouveau_vma *vma = (void *)(unsigned long) bo[push[i].bo_index].user_priv; + u64 addr = vma->addr + push[i].offset; + u32 length = push[i].length & ~NOUVEAU_GEM_PUSHBUF_NO_PREFETCH; + bool no_prefetch = push[i].length & NOUVEAU_GEM_PUSHBUF_NO_PREFETCH; -...

...u/nouveau_gem.c > index f39360870c70..2f3dc4d71657 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c > @@ -856,9 +856,11 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, > void *data, > for (i = 0; i < req->nr_push; i++) { > struct nouveau_vma *vma = (void *)(unsigned long) > bo[push[i].bo_index].user_priv; > + u64 addr = vma->addr + push[i].offset; > + u32 length = push[i].length & > ~NOU...

...veau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index f39360870c70..2f3dc4d71657 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -856,9 +856,11 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, for (i = 0; i < req->nr_push; i++) { struct nouveau_vma *vma = (void *)(unsigned long) bo[push[i].bo_index].user_priv; + u64 addr = vma->addr + push[i].offset; + u32 length = push[i].length & ~NOUVEAU_GEM_PUSHBUF_NO_PREFETCH; + bool prefetch = !(push[i].length & NOUVEAU_GEM_PUSHBUF_NO_PREFETCH); -...

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

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

...drm(&client->device->object); struct nouveau_fifo *fifo = chan->data; struct nouveau_pushbuf_priv *nvpb; struct nouveau_pushbuf *push; @@ -551,7 +552,7 @@ nouveau_pushbuf_new(struct nouveau_client *client, struct nouveau_object *chan, */ req.channel = fifo->channel; req.nr_push = 0; - ret = drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_PUSHBUF, + ret = drmCommandWriteRead(drm->fd, DRM_NOUVEAU_GEM_PUSHBUF, &req, sizeof(req)); if (ret) return ret; -- 2.6.3

https://bugs.freedesktop.org/show_bug.cgi?id=47306 Bug #: 47306 Summary: segfault in nouveau_fence_update Classification: Unclassified Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++----- nouveau/nouveau.c | 56 +++++++------------------------------------------ nouveau/private.h | 7 ++----- 3 files changed, 67 insertions(+), 58 deletions(-) diff --git a/nouveau/abi16.c b/nouveau/abi16.c index

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++