No subject

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 - when I switch to software path, I could track down that it 
> reads data from location C - rendering is done correctly in software path
> - when I comment out freeing of memory manager node (bo.mem.mm_node), so 
> that the third buffer is Z,C (paired with not yet used offset of VRAM) 
> then hardware rendering behaves correctly - but this will make card "run 
> out" of memory as no memory manager nodes will be deallocated
> - when I switch the calls of glCallList into actual rendering code and 
> disable invocation of glNewList/glEndList the hardware rendering also 
> behaves correctly
>
> Any help is appreciated.
>
> Best regards,
> Krzysztof
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>