search for: pushbuf

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not both cur and remai...

...nt32_t buf_cache_frame; } stats; + + struct nouveau_fence_mgr fence; }; static INLINE struct nouveau_context * @@ -91,6 +93,7 @@ nouveau_context_destroy(struct nouveau_context *ctx) if (ctx->scratch.bo[i]) nouveau_bo_ref(NULL, &ctx->scratch.bo[i]); + nouveau_pushbuf_del(&ctx->pushbuf); FREE(ctx); } @@ -106,4 +109,6 @@ nouveau_context_update_frame_stats(struct nouveau_context *nv) } } +int nouveau_context_fence_kick(struct nouveau_fence_mgr *); + #endif diff --git a/src/gallium/drivers/nouveau/nouveau_fence.c b/src/gallium/drivers/nouveau/...

...t; + struct nouveau_fence_mgr fence; > }; > > static INLINE struct nouveau_context * > @@ -91,6 +93,7 @@ nouveau_context_destroy(struct nouveau_context *ctx) > if (ctx->scratch.bo[i]) > nouveau_bo_ref(NULL, &ctx->scratch.bo[i]); > > + nouveau_pushbuf_del(&ctx->pushbuf); > FREE(ctx); > } > > @@ -106,4 +109,6 @@ nouveau_context_update_frame_stats(struct nouveau_context *nv) > } > } > > +int nouveau_context_fence_kick(struct nouveau_fence_mgr *); > + > #endif > diff --git a/src/gallium/drivers/nou...

...mgr = fence->mgr; uint32_t spins = 0; /* wtf, someone is waiting on a fence in flush_notify handler? */ @@ -193,19 +193,19 @@ nouveau_fence_wait(struct nouveau_fence *fence) nouveau_fence_emit(fence); if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED) - if (nouveau_pushbuf_kick(screen->pushbuf, screen->pushbuf->channel)) + if (mgr->flush(mgr)) return FALSE; - if (fence == screen->fence.current) - nouveau_fence_next(screen); + if (fence == mgr->current) + nouveau_fence_next(mgr); do { - nouveau_fence_update(s...

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

...fence->mgr; uint32_t spins = 0; /* wtf, someone is waiting on a fence in flush_notify handler? */ @@ -193,19 +193,19 @@ nouveau_fence_wait(struct nouveau_fence *fence) nouveau_fence_emit(fence); if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED) - if (nouveau_pushbuf_kick(screen->pushbuf, screen->pushbuf->channel)) + if (mgr->flush(mgr)) return FALSE; - if (fence == screen->fence.current) - nouveau_fence_next(screen); + if (fence == mgr->current) + nouveau_fence_next(mgr); do { - nouveau_fence_upda...

...t;> entire notifier, and use a offset in nv30_context_kick_notify. >> It would be great if you could detail the list of transformations that >> were done in the commit description, as well as what the "new way" is >> (if any) for the various concepts. > I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures > that the previous context is flushed. >> This change doesn't have any of the locking -- is that coming in a >> future change? Otherwise we're still vulnerable to multiple threads >> trying...

As far as i see, we reserve the bo in the gem pushbuf ioctl, and unreserve after the pushbuf and the fence have been emitted. This assumption holds if bo moves happen on the same channel or if a cpu copy happens and we're waiting on fences. But for nv50 it is very common for the bo move to happen on the kernel fifo, which does not guarantee anythi...

...- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 64e59fb..75cae79 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -595,7 +595,7 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, void *data, bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo)); if (IS_ERR(bo)) - return (unsigned long)bo; + return PTR_ERR(bo); mutex_lock(&dev->struct_mutex); @@ -622,7 +622,7 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev...

...p to cover the >> entire notifier, and use a offset in nv30_context_kick_notify. > It would be great if you could detail the list of transformations that > were done in the commit description, as well as what the "new way" is > (if any) for the various concepts. I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures that the previous context is flushed. > This change doesn't have any of the locking -- is that coming in a > future change? Otherwise we're still vulnerable to multiple threads > trying to render at the...

...tifier, and use a offset in nv30_context_kick_notify. >>> It would be great if you could detail the list of transformations that >>> were done in the commit description, as well as what the "new way" is >>> (if any) for the various concepts. >> I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures >> that the previous context is flushed. >>> This change doesn't have any of the locking -- is that coming in a >>> future change? Otherwise we're still vulnerable to multiple threads >...

...ng will ever be able to observe that the fence completed. If there are no refs, leave the fence alone and emit it another day. This also happens to work around an issue for the kick handler -- a kick can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be due to lack of space in the pushbuf. We want the emit to happen in the current batch, so we want there to always be enough space. However an explicit kick could take the reserved space for the implicitly-triggered kick's fence emission if it happened right after. With the new mechanism, hopefully there's no way to cause two f...

https://bugs.freedesktop.org/show_bug.cgi?id=93254 Bug ID: 93254 Summary: [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at lists.freedesktop.org...

If you're especially unlucky BOs would move around and their kmaps would end up pointing to something else in GART, then ioctl_pushbuf() would use the kmaps again corrupting textures or other pushbufs (the most noticeable symptom was a PFIFO_DMA_PUSHER from time to time). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 ++ 1 files changed, 2 insertions(+), 0 deleti...

...e dump. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > > # > > # An error report file with more information is saved as: > > # /home/steve/Documents/hs_err_pid26497.log > > nouveau: kernel rejected pushbuf: Invalid argument > > nouveau: ch0: krec 0 pushes 1 bufs 36 relocs 0 > > nouveau: ch0: buf 00000000 00000003 00000004 00000004 00000000 > > nouveau: ch0: buf 00000001 00000003 00000004 00000004 00000000 > > nouveau: ch0: buf 00000002 0000000e 00000002 00000002 00000002 >...

...reak; case PIPE_SHADER_COMPUTE: - if (class_3d > NVE4_3D_CLASS) - return 0; break; default: return 0; @@ -574,11 +572,10 @@ nvc0_screen_init_compute(struct nvc0_screen *screen) case 0xd0: return nvc0_screen_compute_setup(screen, screen->base.pushbuf); case 0xe0: - return nve4_screen_compute_setup(screen, screen->base.pushbuf); case 0xf0: case 0x100: case 0x110: - return 0; + return nve4_screen_compute_setup(screen, screen->base.pushbuf); default: return -1; } Then as soon as I do star...

...te_fini_list(&op->both_list, op->fence); - nouveau_fence_unref((void *)&fence); + validate_fini_list(&op->vram_list, fence); + validate_fini_list(&op->gart_list, fence); + validate_fini_list(&op->both_list, fence); } static int @@ -420,10 +413,6 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan, INIT_LIST_HEAD(&op->gart_list); INIT_LIST_HEAD(&op->both_list); - ret = nouveau_fence_new(chan, &op->fence, false); - if (ret) - return ret; - if (nr_buffers == 0) return 0; @@ -541,6 +530,7 @@ nouveau_gem_ioctl_pushbuf(struc...

..._nouveau.so.2+0x3694] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/steve/Documents/hs_err_pid26497.log nouveau: kernel rejected pushbuf: Invalid argument nouveau: ch0: krec 0 pushes 1 bufs 36 relocs 0 nouveau: ch0: buf 00000000 00000003 00000004 00000004 00000000 nouveau: ch0: buf 00000001 00000003 00000004 00000004 00000000 nouveau: ch0: buf 00000002 0000000e 00000002 00000002 00000002 nouveau: ch0: buf 00000003 00000007 00000002...

...iver in use: nouveau > > > -----Original Message----- > From: ibmirkin at gmail.com [mailto:ibmirkin at gmail.com] On Behalf Of Ilia Mirkin > Sent: April-21-16 11:29 AM > To: Li, Stephen > Cc: nouveau at lists.freedesktop.org > Subject: Re: [Nouveau] nouveau: kernel rejected pushbuf: Invalid argument > > On Thu, Apr 21, 2016 at 11:17 AM, Li, Stephen <Steve.Li at imaginecommunications.com> wrote: >> Hi, >> >> >> >> I am getting a crash in nouveau in my application. It’s basically a >> java application, and I am loading a bitmap in...

http://bugs.freedesktop.org/show_bug.cgi?id=23741 Summary: Driver pixmaps cause pushbuf validation failure on mode change (nv28, KMS) Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau...