   VBO or system mem?
  In a scenario where vertices/indices will be often updated (maybe not once per rendered frame, but at least a couple times per second), does it still make sense to store data in VBOs rather than system memory?Is mapping/updating/unmapping data still substantially faster than using a local memory vertex array and index buffer data pointers? a.   
  I would still guess it is better to use the VBO. There's no requirement that a vbo actually copy data to the gpu, you're just telling the driver "here's some stuff that I plan to use, so do what you feel is best with it". You can even specify GL_DYNAMIC_DRAW as a hint in the vbo to let the driver know you will be changing it often.Client based vertex arrays were deprecated in 3.0, so it seems the ARB doesn't feel there's any point to keeping them around.   ;  Yes. Your vertex data will go through a VBO either way on any reasonable modern system. However, if you keep your data client-side, you burden the driver with some hefty constraints about when it is allowed to do transfers.On the other hand, if you map/unmap a buffer or if you copy data into a buffer object, the driver is thereafter free to do the uploading whenever it wants, and it can do this concurrently to other drawing commands which do not depend on this vertex data. It does not need to do this at the exact time of your primitive draw call.Also, if you tell the GL that the data will be rarely or never modified, it will in all likelihood only do the transfer once and store the data on the graphics card, whereas if the vertex data is client-side, it must be re-uploaded every time, since the driver cannot possibly know if any or all of it has changed.   ;  So be it. I am trying to discard all the pre-Gl3.0 stuff anyway. Thanks a lot for your prompt assistance.   ;  Yes, I can't think of a scenario where I wouldn't recommend VBO's. Just use GL_DYNAMIC_DRAW as usage hint if you intend to update the data. Always update the buffer using glBufferSubData and not glBufferData, as glBufferData causes a reallocation of the buffer. Also, if you use glMapBuffer to update the data (Personally I always use glBufferSubData), make sure you don't 'hop around' the buffer, since the pointer glMapBuffer returns may point to agp memory.EDIT: Seems I was too slow   ;  Yes, use a VBO.  If nothing else it will save an extra memory copy.  Even on older hardware, if you used system mem you would have a scenario where you have raw data -> system memory array -> GPU.  Using a VBO would give you raw data -> GPU directly.Just make certain that you set up your VBO so that it performs well enough in this kind of scenario.   ;Quote:Original post by Rene ZAlso, if you use glMapBuffer to update the data (Personally I always use glBufferSubData), make sure you don't 'hop around' the buffer, since the pointer glMapBuffer returns may point to agp memory.Whoops! This is interesting, please help me understand better. I am using GlMapBuffer infact, right now, to update a rather large GL_ELEMENT_ARRAY_BUFFER. I found the mechanism extremely elegant: just map, get a pointer, cast it to your data type, update, unmap. Is that wrong or slow in anyway?BufferData or even the sub version of it would anyway mean allocating memory, filling it completely (as opposed to just update one or two elements for each "record" of the original buffer), and reuploading it... I hope the mapping/unmapping way is feasible!;  There's nothing wrong with glMapBuffer, but as I said the returned pointer may point to AGP memory. AGP memory is a part of your system memory which is directly accessible by the graphics card. Therefore when you use GL_DYNAMIC_DRAW as usage hint in glBufferData it's likely the driver will store the buffer in AGP memory, as that kind of usage is exactly that it's meant for.However, you can't treat it just like other memory. Your writes must be sequential, or you'll suffer very significant performance drops [queue dramatic music here]. I believe it is okay to skip over a few elements, but never write to a position lower than the last position you've written to.That said, like everything in OpenGL the exact behavior depends on the implementation. The driver may even allocate some system memory, return a pointer to that, and when you unmap the buffer copy it to the actual buffer.   