I have encountered a serious problem with the ARB_vertex_buffer_object extension on nVidia hardware. Specs are as follows: GF4 Ti4600 AGPx4, 53.03 drivers on Win2k, VIA KT600, Athlon XP 2800.
The situation: I’m using a geometry cache (vertices only) to store visible parts of the scene using an LRU scheme. The cache is supposed to be stored in VRAM, as vertex arrays. The current frame is always fully in the cache (no streaming), but when moving the camera, the cache data needs to be updated in regular intervals.
Until recently, I used a vertex_array_range in VRAM to represent that cache. No problems - rendering was fast, and so was the update of the VRAM data. I’m using sequential 4-byte writes to the range.
Then I added a VBO codepath. I’m using one large VBO, initially defined as STATIC_DRAW_ARB, and offsets into it to separate the individual vertex arrays. I’m updating it using mapped memory access (glMapBufferARB with WRITE_ONLY_ARB).
Results: the rendering speed is comparable to VAR, no problems here. But the speed of updating the buffer (mapping/filling/unmapping) is an order of magnitude slower than with VAR, despite using the exact same filling code. With VAR, the updates were unnoticeable, and introduced no visible lag. With VBO, I get lags up to 1 second when updating a larger amount of data. The updating process is easily 30 to 40 times slower than with VAR, using the same writing code !
I tried switching to DYNAMIC_DRAW_ARB (instead of STATIC_DRAW_ARB), but could not notice any difference.
Anyone had similar experiences ?
Thanks for any help,
/ Alex