[Nouveau] More on GART vertex buffer corruption

[Luca Barbieri]

I looked a bit more into the problem of vertex corruption with GART
vertex buffers that disappears putting the buffers in VRAM that I'm
experiencing on my card.
The system I'm seeing this on is a Dell Inspiron 9400 notebook with a
GeForce Go 7900 GS on a PCI Express Intel i945 chipset.

First, I've looked into the behavior of the nVidia driver:
1. On all NV3x and NV4x traces, and my system, vertex buffers are
always put in VRAM (renouveau uses GL_STATIC_DRAW)
2. On my system all vertex object usage flags still cause the vertex
buffer to be put in VRAM
3. On my system GL_NV_vertex_range causes the use of a GART vertex
buffer, and seems the only way to do so

Note that statement 2 may not be true for all NV3x/NV4x cards.
It would be interesting to see the output of the attached renouveau
tests on other cards.

glFlushVertexArrayRangeNV does the following:
# 14 NOPs
00043710  size 1, subchannel 1 (0xbeef3097),offset 0x1710,increment
00000000    NV40TCL[0x1710/4]
00043d6c  size 1, subchannel 1 (0xbeef3097),offset 0x1d6c,increment
00000580    NV40TCL[0x1d6c/4]
00043d70  size 1, subchannel 1 (0xbeef3097),offset 0x1d70,increment
0000000b    NV40TCL[0x1d70/4]
00042104  size 1, subchannel 1 (0xbeef3097),offset 0x0104,increment
00000000    NV40TCL.NOTIFY
00042100  size 1, subchannel 1 (0xbeef3097),offset 0x0100,increment
00000000    NV40TCL.NOP
And probably waits for the fence afterwards.

0x1710 does something relating to vertex buffer caching.
0x1d6c and 0x1d70 are a 3D engine fence emission.

Adding 0x1710 and waiting for our usual fences both before and after
draw_elements did not fix the problem.
I haven't tried using the 3D fencing mechanism.

It seems we might be better off always putting vertex buffers in VRAM,
since the blob does so and while writing to them might be a bit
slower, the required synchronization may be even worse.

I attached a renouveau test for GL_NV_vertex_array_range and one for
all the glBufferData flags. The quality of the code is quite low but
it should do the job.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: renouveau-tests.c
Type: text/x-csrc
Size: 4466 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/nouveau/attachments/20100115/f10f8ac7/attachment.c