NV VAR renders while CPU's free

Hi,
I’m rendering my scene with NV Vertex Array Range and after that I change data in that buffer. It causes errors, beacuse while I’m changing data (after rendering function DrawElements) scene is still being rendered from that buffer. Do you know how to wait until the scene is rendered (buffer isn’t used)? I’m doing glFlush after rendering functions but it doesn’t make program to wait for full render.

I don’t know if my english is enough to explain this problem…

Check this demo
http://developer.nvidia.com/object/vardemo.html

But you might want to look into vertex buffer objects (VBO) which are easier to use and implemented by more vendors.

VAR is deprecated.
Don´t even think of using it.
Use VBO.

Jan.

The spec says:
“When the vertex array range is valid, the vertex array coherency
model is relaxed so that changes made to array data until the next
“vertex array range flush” may affects calls to ArrayElement in
non-sequential ways. That is a call to ArrayElement that precedes
a change to array data (without an intervening “vertex array range
flush”) may access the changed data, and a call that follows a change
(without an intervening “vertex array range flush”) to array data
may access original data.”

To enforce coherency, you can use glFlushVertexArrayRangeNV.

NV_fence may be useful, too.

VAR is maybe “deprecated” but it’s still usefull. All the Geforce fx PCI cards i have tested, for some reason, are extremely slow with VBOs. Using VAR is the only way i’ve found to get “correct” performance.

Y.

Users often have older drivers, that don’t even support VBO. Thus, you need a VAR path if you care about performance and compatibility. And, as others said, the right solution to the sychronization problem in that case is NV_fence. Flushing the vertex array range causes noticeable stalls.

Additionally, initial implementations of VBO on NVIDIA drivers were slow, so we don’t turn on VBO unless users have recent enough drivers that it’s actually comparable to VAR in performance.