search for: nouveau_fence_work

...t;object; + + fctx->lock = &pfifo->uevent->list_lock; INIT_LIST_HEAD(&fctx->flip); INIT_LIST_HEAD(&fctx->pending); - spin_lock_init(&fctx->lock); + + snprintf(fctx->name, sizeof(fctx->name) - 1, "nouveau channel %i", fifo->chid); } +struct nouveau_fence_work { + struct work_struct work; + struct fence_cb cb; + void (*func)(void *); + void *data; +}; + static void nouveau_fence_work_handler(struct work_struct *kwork) { - struct fence_work *work = container_of(kwork, typeof(*work), base); + struct nouveau_fence_work *work = container_of(kwork, typeof(...

...; - } while (nv->scratch.nr_runout); - FREE(nv->scratch.runout); + struct bos *b = MALLOC(sizeof(*b)); + b->arr = nv->scratch.runout; + b->nr = nv->scratch.nr_runout; + + struct nouveau_fence *fence = NULL; + nouveau_fence_new(nv->screen, &fence, TRUE); + nouveau_fence_work(fence, unref_bos, b); + nv->scratch.end = 0; nv->scratch.runout = NULL; + nv->scratch.nr_runout = 0; } /* Allocate an extra bo if we can't fit everything we need simultaneously. -- 2.1.0

...vers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 9a9e04985826..b1aba6f79605 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -139,17 +139,18 @@ static bool nouveau_fence_is_signaled(struct fence *f) } void -nouveau_fence_work(struct nouveau_fence *fence, +nouveau_fence_work(struct fence *fence, void (*func)(void *), void *data) { struct nouveau_fence_work *work; - if (fence_is_signaled(&fence->base)) + if (fence_is_signaled(fence)) goto err; work = kmalloc(sizeof(*work), GFP_KERNEL); if (!work...

...?? () #7 0x0000000000405bc9 in ?? () #8 0x00007fffd72eb304 in ?? () from ./libs/libref_gl_x86_64.so #9 0x00007ffff78bc6aa in start_thread (arg=0x7fffe704a700) at pthread_create.c:333 #10 0x00007ffff70e1eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) print work $1 = (struct nouveau_fence_work *) 0x7fffd815fc50 (gdb) print work->list $2 = {prev = 0x0, next = 0x7fffd8121510} (gdb) list 52 { 53 struct nouveau_fence_work *work, *tmp; 54 55 LIST_FOR_EACH_ENTRY_SAFE(work, tmp, &fence->work, list) { 56 work->func(work->data); 57 LIST_DEL(&a...

...vers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index d24f8ce4341a..9f92ad37637d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -139,17 +139,18 @@ static bool nouveau_fence_is_signaled(struct fence *f) } void -nouveau_fence_work(struct nouveau_fence *fence, +nouveau_fence_work(struct fence *fence, void (*func)(void *), void *data) { struct nouveau_fence_work *work; - if (fence_is_signaled(&fence->base)) + if (fence_is_signaled(fence)) goto err; work = kmalloc(sizeof(*work), GFP_KERNEL); if (!work...

Hello everyone, it seems that GP10B support has regressed recently. With linux-next, I need to modify device/base.c to set .mmu = gp10b_mmu_new for GP10B (makes sense - I guess this was left as gf100_mmu_new as a typo) to probe. After that, running a trivial testcase (running a NOP method in 3D class) fails with [ 110.084649] nouveau 17000000.gpu: fifo: read fault at 0000011000 engine 06

...uveau_fence **fence, boolean emit) { *fence = CALLOC_STRUCT(nouveau_fence); if (!*fence) return FALSE; - (*fence)->screen = screen; + (*fence)->mgr = mgr; (*fence)->ref = 1; LIST_INITHEAD(&(*fence)->work); @@ -83,7 +83,7 @@ nouveau_fence_work(struct nouveau_fence *fence, void nouveau_fence_emit(struct nouveau_fence *fence) { - struct nouveau_screen *screen = fence->screen; + struct nouveau_fence_mgr *mgr = fence->mgr; assert(fence->state == NOUVEAU_FENCE_STATE_AVAILABLE); @@ -92,14 +92,14 @@ nouveau_fence_e...

Bisection status report: The latest commit I have gotten to work is 10842ba074e9 drm/nouveau: remove unused nouveau_fence_work() i.e. the first bad commit is d7722134b825 drm/nouveau: switch over to new memory and vmm interfaces Even with the first one some patches/hacks are needed: - in mmu/gp10b.c, in the constructor we need to select the GM200 path - the GP100 path seems to not to work - as mentioned in the first...

...[<ffffffffa02d5cdb>] ? nouveau_mm_free+0x85/0x116 [nouveau] [<ffffffffa02f57c9>] nouveau_vm_put+0x9a/0xb0 [nouveau] [<ffffffffa033462d>] ? nouveau_gem_info+0x9d/0x9d [nouveau] [<ffffffffa0334646>] nouveau_gem_object_delete+0x19/0x28 [nouveau] [<ffffffffa032fc90>] nouveau_fence_work+0xc9/0x102 [nouveau] [<ffffffffa0334d59>] nouveau_gem_object_close+0x103/0x182 [nouveau] [<ffffffffa01d8bcd>] drm_gem_handle_delete+0xcc/0x153 [drm] [<ffffffffa01d8fc5>] drm_gem_close_ioctl+0x23/0x25 [drm] [<ffffffffa01d6f75>] drm_ioctl+0x4cc/0x612 [drm] [<ffffffff81...

...struct nouveau_fence **fence, boolean emit) { *fence = CALLOC_STRUCT(nouveau_fence); if (!*fence) return FALSE; - (*fence)->screen = screen; + (*fence)->mgr = mgr; (*fence)->ref = 1; LIST_INITHEAD(&(*fence)->work); @@ -83,7 +83,7 @@ nouveau_fence_work(struct nouveau_fence *fence, void nouveau_fence_emit(struct nouveau_fence *fence) { - struct nouveau_screen *screen = fence->screen; + struct nouveau_fence_mgr *mgr = fence->mgr; assert(fence->state == NOUVEAU_FENCE_STATE_AVAILABLE); @@ -92,14 +92,14 @@ nouveau_fence_emit(st...

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic

...fence, boolean emit) diff --git a/src/gallium/drivers/nouveau/nouveau_fence.h b/src/gallium/drivers/nouveau/nouveau_fence.h index cb44dd3..cdc60ed 100644 --- a/src/gallium/drivers/nouveau/nouveau_fence.h +++ b/src/gallium/drivers/nouveau/nouveau_fence.h @@ -32,10 +32,10 @@ struct nouveau_fence_work { }; struct nouveau_fence { + int32_t ref; struct nouveau_fence *next; struct nouveau_fence_mgr *mgr; int state; - int ref; uint32_t sequence; struct list_head work; }; @@ -55,10 +55,10 @@ static INLINE void nouveau_fence_ref(struct nouveau_fence *fence, struct nouveau...

...boolean emit) > diff --git a/src/gallium/drivers/nouveau/nouveau_fence.h b/src/gallium/drivers/nouveau/nouveau_fence.h > index cb44dd3..cdc60ed 100644 > --- a/src/gallium/drivers/nouveau/nouveau_fence.h > +++ b/src/gallium/drivers/nouveau/nouveau_fence.h > @@ -32,10 +32,10 @@ struct nouveau_fence_work { > }; > > struct nouveau_fence { > + int32_t ref; > struct nouveau_fence *next; > struct nouveau_fence_mgr *mgr; > int state; > - int ref; > uint32_t sequence; > struct list_head work; > }; > @@ -55,10 +55,10 @@ static INLINE void >...

On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > drivers/gpu/drm/radeon/radeon.h | 15 +- > drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++- > drivers/gpu/drm/radeon/radeon_fence.c | 223 ++++++++++++++++++++++++++------ > 3 files

...KM_VMM_PAGE_SxHx }, {} } on top of next-20171121 works at least for a simple test. Mikko On 11/11/2017 03:02 PM, Mikko Perttunen wrote: > Bisection status report: > > The latest commit I have gotten to work is > > 10842ba074e9 drm/nouveau: remove unused nouveau_fence_work() > > i.e. the first bad commit is > > d7722134b825 drm/nouveau: switch over to new memory and vmm interfaces > > Even with the first one some patches/hacks are needed: > > - in mmu/gp10b.c, in the constructor we need to select the GM200 path - > the GP100 path seems...

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

...m2mf_transfer_rect(nv50, &tx->rect[0], &tx->rect[1], tx->nblocksx, tx->nblocksy); @@ -362,6 +367,7 @@ nv50_miptree_transfer_unmap(struct pipe_context *pctx, /* Allow the copies above to finish executing before freeing the source */ nouveau_fence_work(nv50->screen->base.fence.current, nouveau_fence_unref_bo, tx->rect[1].bo); + pipe_mutex_unlock(nv50->screen->base.push_mutex); } else { nouveau_bo_ref(NULL, &tx->rect[1].bo); } diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo...