hi, you have ALOT of questions :p

first off:
- ARB_vertex_buffer_object or VBO is essentialy the ARB form of NV_vertex_array_range.

- AGP memory is the memory on your video card.

your question about how to allocate memory on your video card, VBO's allow you to do this, thats why they are so fast, there isnt any need to transfer data from the system memory, rather you just work on it while its in the vid mem.

for a 20K object its hard to say because different situations require different approaches, for speed, its safe to say use VBO's

VertexArrays are the "old-skool" way of doing it, tried and tested.
still very usefull these days and i forsee for a while.

there are quite a few tutorials on the net, a good place to start would be http://www.codesampler.com

hope that answered some of your questions.
Cheers.

Quote:Original post by silvermace
- ARB_vertex_buffer_object or VBO is essentialy the ARB form of NV_vertex_array_range.

more or less at least. id rather say vbo replaced var and is closer to atis vao.

Quote:
- AGP memory is the memory on your video card.

*cough* have a look at your bios settings and the explanation for agp aperture size. video memory is memory on the video card.

Quote:rather you just work on it while its in the vid mem.

it wont be fast if you work on it too much. reading from video memory is a big no no and if you have to update the data every frame then i doubt using video memory has any advantage over agp memory.

Quote:
VertexArrays are the "old-skool" way of doing it, tried and tested.
still very usefull these days and i forsee for a while.

they could already be obsolete if vbo would allow a little more control and have a not so bewildering fallback method (if any at all). having simply "buffers" would be nice and that seems to be coming. pixelbufferobjects are the next step and being able to bind buffers as vertex or pixel buffer hint at soon just saying "its a buffer.. it has a lot of numbers inside" and losing any distinction between texture, vertex buffer, pixel buffer objects.

so far the example looks like still having to render to a framebuffer and copy it to a pixelbuffer that is then bound as vertex buffer. wouldnt it be much easier to directly render to a pixelbuffer just like rendering to a texture?

anyway, not the topic.

buffers are like textures...

glGenBuffers works like glGenTextures
glDeleteBuffers like glDeleteTextures
glBindBuffer like glBindTexture
glBufferData has the same use as glTexImage

and specifying the usage is a hint to the driver, but its free to place it wherever it likes and handle the management for you (so if you have a lot of static data instead of breaking your head if you can afford putting it in video memory or not this decision is up to the driver). i wouldnt mind more control like "often reading means system memory" or "updating every frame means agp memory" and "updated once around every christmas means video memory".

My mistake on the AGP memory...

heres a proper explination of AGP memory.