similar to: No subject

It seems that Noveau is assuming that once the FIFO pointer is past a command, that command has finished executing, and all the buffers it used are no longer needed. However, this seems to be false at least on G71. In particular, the card may not have even finished reading the input vertex buffers when the pushbuffer "fence" triggers. While Mesa does not reuse the buffer object itself,

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

Requesting a new real buffer from the kernel and copying all the data is wasteful e.g. if only a few (but widely spread) vertices are accessed. --- src/gallium/drivers/nv50/nv50_context.h | 3 + src/gallium/drivers/nv50/nv50_vbo.c | 409 +++++++++++++++++++++++++++++-- 2 files changed, 394 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_context.h

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,

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 +++

- 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

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

- 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 ++++++++++++++

http://bugs.freedesktop.org/show_bug.cgi?id=25806 Summary: NV40 vertex corruption (kernel BO deletion too early?) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org

Add proper flushes for TIC and TSC and remove the costly 2D.0110 flush in nv50_flush. Correct TIC and TSC bo sizes. --- src/gallium/drivers/nv50/nv50_context.c | 7 --- src/gallium/drivers/nv50/nv50_context.h | 5 ++ src/gallium/drivers/nv50/nv50_screen.c | 25 ++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 53 +++++++++++++++++++++---

Fixes the piglits which check that gl_VertexID includes the base vertex offset: arb_draw_indirect-vertexid elements gl-3.2-basevertex-vertexid Note that this leaves out the original G80, for which this will continue to fail. It could be fixed by passing a driver constbuf value in, but that's beyond the scope of this change. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc:

Op 11-08-13 10:04, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > >> I think I found at least two cases where "12" was used where it should >> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This >> is only the tip of the iceberg, so this isn't a formal patch submission, >> but I would

On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > >> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c >> > index 5c7433d..c314a5f 100644 >> > ---

- 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 +++++++++++++

- 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 +++

So, basically, you allocate the rasterizer units according to the vertex shader, and when the fragment shader comes up, you say "write rasterizer output 4 to fragment input 1000000"? The current nouveau drivers can't do this. There are "routing" registers in hardware, but I think the nVidia proprietary driver (at least without GLSL) leaves them unaltered after

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 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 +++++++++++++++++++-

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > I think I found at least two cases where "12" was used where it should > have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This > is only the tip of the iceberg, so this isn't a formal patch submission, > but I would appreciate your thought as to whether the below is correct > (and thus

Just wanted to communicate some thoughts I had while reading the diffs, even thought I didn't have the time to look at everything in detail yet. - nv50: use relocs rather than re-uploading TIC all the time It's nice that we can write relocs to arbitrary buffers, and it's much less work than emitting the whole state object obviously. Just, you forgot the card won't care until you