[Nouveau] [PATCH] nouveau: don't emit reloc markers for bo's that are mapped

[Maarten Maathuis]

On Fri, Dec 18, 2009 at 10:57 AM, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> wrote:
> Maarten Maathuis schrieb:
>> Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>
>> ---
>>  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
> Nouveau at lists.freedesktop.org
> 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.