On Fri, Dec 18, 2009 at 10:57 AM, Christoph Bumiller <[email protected]> wrote: > Maarten Maathuis schrieb: >> Signed-off-by: Maarten Maathuis <[email protected]> >> --- >> src/gallium/drivers/nouveau/nouveau_stateobj.h | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h >> b/src/gallium/drivers/nouveau/nouveau_stateobj.h >> index 9aee9e4..6c40f64 100644 >> --- a/src/gallium/drivers/nouveau/nouveau_stateobj.h >> +++ b/src/gallium/drivers/nouveau/nouveau_stateobj.h >> @@ -163,6 +163,15 @@ so_emit_reloc_markers(struct nouveau_channel *chan, >> struct nouveau_stateobj *so) >> for (i = 0; i < so->cur_reloc; i++) { >> struct nouveau_stateobj_reloc *r = &so->reloc[i]; >> >> + /* This is probably a vbo which has caused a pushbuf flush >> + * before mapping. Don't try to reloc it again, it will cause > don't you mean un-mapping here ? >> + * problems, because important stuff is skipped. >> + */ >> + if (r->bo->map) { >> + pb->remaining += 2; >> + continue; >> + } >> + > Should that be able to happen ? > I mean, the state tracker probably should have unmapped the VBOs again > before making us to use them for drawing (or doesn't it ?), and if *we* > mapped the VBO because we're using the VERTEX_DATA immediate mode, there > should be no relocation in any of the state objects we emit relocation > markers for. > > Btw. in case of an error in the immediate path (i.e. if the vertex > element is invalid) I forgot to unmap the vbufs again, and there > might be double unmap in in nv50_map_vbufs because I didn't check if > map was NULL there. >> if ((ret = nouveau_pushbuf_emit_reloc(chan, pb->cur++, r->bo, >> r->packet, 0, >> (r->flags & (NOUVEAU_BO_VRAM | > > Christoph > (sorry, forgot to CC to the list in first send) > _______________________________________________ > Nouveau mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/nouveau >
What i think is happening here (a bit of a guess, adjusted as i wrote it here, because my first idea was wrong). VBO is used, vbo is filled, vbo state is emitted, vbo/pipe buffer is mapped (by the statetracker), but libdrm_nouveau realizes that the pushbuf needs a flush. At that point reloc markers in flush notify is fine, since it happens before the map. But if the pushbuf gets flushed again, the the reloc markers will try to emit a buffer that is mapped. This is the only thing i can think off, but i admit i still see kernel warnings about trying to emit buffers which are mapped by same process sometimes. So i will have a closer look at the vbo code soon. Maarten. _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
