similar to: [PATCH 3/7] nv50: submit user vbo data through the fifo

NOTE: we must not try to emit buffer relocations when vtxbuf_nr is 0 but vtxelt_nr is not --- src/gallium/drivers/nv50/nv50_vbo.c | 80 ++++++++++++++++++++++++---------- 1 files changed, 56 insertions(+), 24 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_vbo.c b/src/gallium/drivers/nv50/nv50_vbo.c index cbd9d6a..422c8c6 100644 --- a/src/gallium/drivers/nv50/nv50_vbo.c +++

https://bugs.freedesktop.org/show_bug.cgi?id=56474 Priority: medium Bug ID: 56474 Assignee: nouveau at lists.freedesktop.org Summary: 3D app segfaults on NV46 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: 1o5g4r8o at gmail.com Hardware: x86 (IA32) Status: NEW

The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "11.0" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_program.h | 1 +

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 22 ++++++++++++++++++- src/gallium/drivers/nouveau/nv50/nv50_context.h | 1 + src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 29 ++++++++++++++++++++++++- 3 files changed, 50 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++

Hi all! I saw TODO comment in nv50_vbo.c and decided to look at similar file, nvc0_vbo.c. I copied those two lines into nv50 with slight name change (nvc0->nv50) and apparently it doesn't fix any OpenGL app I have, but does not broke them further (I have compute pacthes currently applied, so some breakage expected). diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. - Also add one nouveau_bo_unmap() in the vbo code that wasn't present. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++

- This avoids some problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 20 +++++++++++++++++++-

a fence in the command stream when you change the vtxbuf addresses, on nv50 that is, I don't know about nv40, sorry. But it *did* look like the blob inserts a fence after *uploading* new data to a vertex buffer. That's why there's method 0x142c in nv50_draw_arrays. > Other observations: > - the data during execution of gl commands actually seems to be put into > location C -

The current code for primitive splitting and emission on pre-nv50 is severely broken. In particular: 1. Quads and lines are totally broken because "&= 3" should be "&= ~3" and similar for lines 2. Triangle fans and polygons are broken because the first vertex must be repeated for each split chunk 3. Line loops are broken because the must be converted to a line strip,

- unreference state objects so that buffer objects are unreferenced and eventually destroyed - free channel at screen's destruction Index: nv50/nv50_screen.c =================================================================== --- nv50/nv50_screen.c (wersja 32083) +++ nv50/nv50_screen.c (kopia robocza) @@ -162,7 +162,22 @@ nv50_screen_destroy(struct pipe_screen *pscreen) { struct

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]:

Hi, My name is Krzysztof and currently I'm working on porting nouveau (gallium3d driver + libdrm + drm) to AROS Research OS (http://www.aros.org). I completed a quite successful port of "old" drm (one from libdrm git - now removed) and currently I'm working on drm port from the nouveau kernel tree git. Right now I'm faced with rather peculiar memory allocation/access

- NV30 and NV40 need testing. - I'll take better naming suggestions for so_get_push_reloc(). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 49 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++- src/gallium/drivers/nv30/nv30_state_emit.c | 26 ++++++++++++ src/gallium/drivers/nv40/nv40_state_emit.c | 30 ++++++++++++++

This makes the vertex buffer go to GART, not VRAM, and redoes the mapping to not use the UNSYNCHRONIZED access (which is meaningless on a VRAM buffer anyways). While we're at it, add some flushes for VBO data. Moving the vertex buffer from VRAM to GART makes glxgears work fully with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not sure *why* moving the buffer from VRAM

This moves construction of the mapping between VP outputs and FP inputs into validation. The map also contains slots for special outputs like clip distance and point size, so we need to at least merge the VP related and FP related parts on validation if we want to support those. Now we match every single FP input component with results from the VP and leave those not read out of the map, or

--- This is still a WIP. Just wanted to get people's opinions. It's also not bullet-proof. Unfortunately nouveau_bo_wait [which is in turn called by nouveau_bo_map] can trigger a kick, so technically we have to have a lock around any nouveau_bo_map. My strategy here was to add locks around all the user-accessible APIs while leaving all the internal stuff unlocked. When waiting for a

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 +

On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > 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. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the