The problem with glVertexPointer() and its
friends is that there is no good locking
semantics. Further, because the application
allocates the memory for glVertexPointer()
in the normal case, transfer to a hardware
transform/lighting card will sometimes be
sub-optimal, because memory allocated with
malloc() (or even just globals) will neither
be physically contiguous nor in easily
accessible AGP memory.
These are exactly the problems that the
vertex buffer memory allocation and fence
extesions are intended to solve. Use them if
they are available and it makes sense.
However, dollars to donuts that geometry
upload is not your main limiting factor.
Just using glVertexPointer() and friends will
probably remove most of the transfer
bottleneck, and you could move on to trying
to minimize texture fill and speed up your
AI/physics/whatever is operating on the data
in the first place.
If your geometry is truly static, you may be
able to use the compiled vertex array
extension to put the data in AGP memory or
on the card, without having to manage the
memory yourself. However, the use notes for
LockArrayEXT and UnlockArrayEXT say that any
state change (glTranslate(), glRotate() etc)
could cause the locked data to be invalidated
and thus the locking might be less efficient.
Also, it states that using glDrawElement()
and friends on a range outside of that which
is locked is undefined. Further, you cannot
use more than one locked array at a time, so
if you’re drawing anything other than your
static geometry, you’ll have to unlock to
draw those other things anyway.
[This message has been edited by bgl (edited 12-17-2000).]