search for: nouveau_buff

...al to radeon's use, so perhaps this is OK to check in without extensive testing and we can revert later if it should cause problems? It's unlikely to have a drastic effect there though, due to implementation differences. Testing would be very much appreciated. src/gallium/drivers/nouveau/nouveau_buffer.c | 29 ++++++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_buffer.h | 4 ++++ src/gallium/drivers/nouveau/nv50/nv50_resource.c | 2 ++ src/gallium/drivers/nouveau/nv50/nv50_state.c | 4 ++++ src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 2 ++ src/gallium/drivers/nouv...

...when hardware advances to this place in the command stream the scratch buffers can be freed". The bug existed for a very long time. Nobody noticed, because "scratch runout" code path is rarely executed. Fixes "Serious Sam 3" on nve7/gk107. --- src/gallium/drivers/nouveau/nouveau_buffer.c | 33 +++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c b/src/gallium/drivers/nouveau/nouveau_buffer.c index 49ff100..e649752 100644 --- a/src/gallium/drivers/nouveau/nouveau_buffer.c +++ b/src/gallium/driver...

...s my shot at understanding this whole transfer business. The upshot is that after reading through it and understanding it, the transfer logic does appear correct if potentially less-than-perfectly-efficient (e.g. one could keep track of ranges being read/written, etc). src/gallium/drivers/nouveau/nouveau_buffer.c | 71 +++++++++++++++++++++++++++- src/gallium/drivers/nouveau/nouveau_buffer.h | 4 +- 2 files changed, 71 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c b/src/gallium/drivers/nouveau/nouveau_buffer.c index 95905a8..0b21530 100644 --- a/src/gallium/dr...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +--- src/gallium/drivers/nouveau/nouveau_context.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c b/src/gallium/drivers/nouveau/nouveau_buffer.c index e308ff4..904e2cc 100644 --- a/src/gallium/drivers/nouveau/nouveau_buffe...

...<acourbot at nvidia.com> wrote: > Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative > VRAM domains for chips that do not use dedicated video memory. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- > src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- > src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++-- > src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c |...

This fixes a memory leak in some situations. Also avoids emitting an extra fence if the kick handler does the call to nouveau_fence_next itself. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "9.2 10.0" <mesa-stable at lists.freedesktop.org> --- TBH I'm pretty confused by the whole fence refcounting logic and its interaction with emits, updates, etc. However

...ch systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. Alexandre Courbot (2): nouveau: support for custom VRAM domains nvc0: use NV_VRAM_DOMAIN() macro src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- src/gallium/drivers/nouveau/nouveau_screen.c | 10 ++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 4 ++++ src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- src/ga...

...Changes since v1: - When using GART as the VRAM domain, move all vidmem bindings to sysmem and set vidmem_bindings to 0. Alexandre Courbot (3): nouveau: support for custom VRAM domains nvc0: use NV_VRAM_DOMAIN() macro gk20a: use NOUVEAU_BO_GART as VRAM domain src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++--- src/gallium/drivers/nouveau/nouveau_screen.c | 6 +++++ src/gallium/drivers/nouveau/nouveau_screen.h | 4 ++++ src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- src/gallium/drivers/nouveau/nv...

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative VRAM domains for chips that do not use dedicated video memory. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 2 +- src/gallium/...

...V_VRAM_DOMAIN() macro to support alternative > VRAM domains for chips that do not use dedicated video memory. Should we construct a similar patch for NVAA/NVAC (MCP7x) as well? > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- > src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- > src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++-- > src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c...

...nd all things taken is not very intrusive. Tested on GK20A with Wayland and several EGL clients running, and working fine. Alexandre Courbot (3): nouveau: support for custom VRAM domains nvc0: use NV_VRAM_DOMAIN() macro gk20a: use NOUVEAU_BO_GART as VRAM domain src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- src/gallium/drivers/nouveau/nouveau_screen.c | 6 ++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 4 ++++ src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +- src/gallium/drivers/nouveau/...

...bthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt full #0 0x00000000 in ?? () No symbol table info available. #1 0xb6785c26 in nouveau_transfer_write (nv=nv at entry=0x805cc70, tx=tx at entry=0x82fece0, offset=offset at entry=0, size=128) at nouveau_buffer.c:185 buf = 0x8294668 data = 0x8309740 "\002?" base = 0 can_cb = 1 '\001' #2 0xb67860a7 in nouveau_buffer_transfer_unmap (pipe=0x805cc70, transfer=0x82fece0) at nouveau_buffer.c:413 buf = 0x8294668 #3 0xb69a2c8a in u_transfer_unmap_vtbl...

https://bugs.freedesktop.org/show_bug.cgi?id=99354 Bug ID: 99354 Summary: [G71] "Assertion `bkref' failed" reproducible with glmark2 Product: Mesa Version: 13.0 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...this, the various glx-multithread tests pass on nv50, nvc0. I still need to hook this up for nv30. I also need to hook up the vdec bits of it. I would be curious if people could test this out and see what effect it has on their workloads, or if I messed something up. src/gallium/drivers/nouveau/nouveau_buffer.c | 29 +++++++++-- src/gallium/drivers/nouveau/nouveau_fence.c | 18 +++++++ src/gallium/drivers/nouveau/nouveau_fence.h | 5 +- src/gallium/drivers/nouveau/nouveau_screen.c | 12 ++++- src/gallium/drivers/nouveau/nouveau_screen.h | 3 ++ src/gallium/drivers/nou...

...d28d in memcpy (__len=48, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string3.h:53 #2 0x00007f5be066d28d in nouveau_scratch_data (nv=nv at entry=0x1dc0800, data=<optimized out>, base=base at entry=0, size=size at entry=48, bo=bo at entry=0x7ffc23880868) at nouveau_buffer.c:1004 #3 0x00007f5be078bba9 in nvc0_update_user_vbufs_shared (nvc0=0x1dc0800) at nvc0/nvc0_vbo.c:292 #4 0x00007f5be078121d in nvc0_state_validate (nvc0=nvc0 at entry=0x1dc0800, mask=mask at entry=4294967295, validate_list=validate_list at entry=0x7f5be0d78fe0 <validate_list_3d>, size=siz...

nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 + src/gallium/drivers/nouveau/nouveau_fence.c | 10 + src/gallium/drivers/nouveau/nouveau_fence.h | 6 +- src/gallium/drivers/nouveau/nouveau_screen.c | 16 -- src/gallium/drivers/nouveau/nouveau_s...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-

...red by everything... Have you done a full piglit run on this (with the glx tests, for good measure) on nv30/nv50/nvc0? If so, can you share the results files somewhere? > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- > src/gallium/drivers/nouveau/nouveau_context.h | 5 + > src/gallium/drivers/nouveau/nouveau_fence.c | 10 + > src/gallium/drivers/nouveau/nouveau_fence.h | 6 +- > src/gallium/drivers/nouveau/nouveau_screen.c | 16 -- > src/gallium/...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4

https://bugs.freedesktop.org/show_bug.cgi?id=99396 Bug ID: 99396 Summary: Crash in nouveau_dri.so when switching apps with alt-tab in Gnome Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau