search for: pushbuf_flush

...lt;string.h> #include <assert.h> #include <errno.h> +#include <unistd.h> #include <xf86drm.h> #include <xf86atomic.h> @@ -77,7 +78,7 @@ nouveau_pushbuf(struct nouveau_pushbuf *push) } static int pushbuf_validate(struct nouveau_pushbuf *, bool); -static int pushbuf_flush(struct nouveau_pushbuf *); +static int pushbuf_flush(struct nouveau_pushbuf *, int *); static bool pushbuf_kref_fits(struct nouveau_pushbuf *push, struct nouveau_bo *bo, @@ -172,7 +173,7 @@ pushbuf_kref(struct nouveau_pushbuf *push, struct nouveau_bo *bo, */ fpush = cli_push_get(push->c...

...00x2500 pixmap in firefox with 64mb vram. After talking a bit more with curro, I started to write a patch. I don't know how bad and wrong it is, there are still so many things I don't understand. It seems it works somehow, meaning OUT_RELOC -> emit_reloc will fail before FIRE_RING -> pushbuf_flush. But enomem failures during pushbuf_flush still happen. And worse, what happens after an OUT_RELOC failure is awful : 1) on nv25, the system freezes for 5 seconds, and after the lower part (a rectangle) of the picture seems to have a wrong offset or something. 2) on nv84 (hacked to force 64mb vram)...

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

...n at entry=0x8613cf8) at nouveau_fence.c:227 #4 0xb5ce9a83 in nvc0_default_kick_notify (push=0x8614038) at nvc0/nvc0_context.c:170 #5 0xb5b8a04e in pushbuf_submit (push=push at entry=0x8614038, chan=<optimized out>, chan=<optimized out>) at pushbuf.c:325 #6 0xb5b8a39a in pushbuf_flush (push=push at entry=0x8614038) at pushbuf.c:402 #7 0xb5b8ad27 in nouveau_pushbuf_space (push=push at entry=0x8614038, dwords=0, relocs=0, pushes=<optimized out>, pushes at entry=0) at pushbuf.c:676 #8 0xb5b8ade3 in pushbuf_validate (push=0x8614038, retry=<optimized out>) at p...

...cgi?id=1001714 https://bugzilla.redhat.com/show_bug.cgi?id=1001698 https://bugzilla.redhat.com/show_bug.cgi?id=1001740 I see always problem w/ pushbuf_dump. It's crashing w/ SIGSEGV. The same of: Thread no. 1 (10 frames) #0 pushbuf_dump at pushbuf.c:296 #1 pushbuf_submit at pushbuf.c:361 #2 pushbuf_flush at pushbuf.c:402 #3 nouveau_pushbuf_kick at pushbuf.c:773 #4 PUSH_KICK at ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:56 #5 nvc0_flush at nvc0_context.c:45 #6 st_glFlush at ../../src/mesa/state_tracker/st_cb_flush.c:121 #7 _mesa_make_current at ../../src/mesa/main/context.c:1455...

...40, bo=bo at entry=0x0, offset=offset at entry=0, length=length at entry=0) at ../../nouveau/pushbuf.c:718 #6 0x00007fffe1d762ea in pushbuf_submit (push=push at entry=0x598d40, chan=<optimized out>, chan=<optimized out>) at ../../nouveau/pushbuf.c:329 #7 0x00007fffe1d7656e in pushbuf_flush (push=push at entry=0x598d40) at ../../nouveau/pushbuf.c:404 #8 0x00007fffe1d77180 in nouveau_pushbuf_kick (push=0x598d40, chan=<optimized out>) at ../../nouveau/pushbuf.c:778 #9 0x00007fffe246d766 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x00007fffe2182024 in ?? () fr...

https://bugs.freedesktop.org/show_bug.cgi?id=90482 Bug ID: 90482 Summary: Xorg take 100% CPU when using multiple independent screen configuration Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

https://bugs.freedesktop.org/show_bug.cgi?id=92438 Bug ID: 92438 Summary: Segfault in pushbuf_kref when running the android emulator (qemu) on nv50 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium