Hello,

I am using VBO's together with glDrawElements to quickly render a bunch of triangles. In my case, since each triangle has exactly 3 vertices, 3 normals and 3 texture coordinates, I could get rid of the indices and avoid having another VBO taking memory on the GPU.

My indices are always starting at zero and continuous.

Is there a way to avoid having to upload those indices?

Another option would be to have one single index buffer on the GPU that serves all the geometries that I need to render, but that is still taking some memory on the GPU.

Finally, and linked to the VBO's: how do people usually handle situations where there is no more free memory on the GPU for VBOs:

- how to notice that?

- how to overcome that?

Thanks!

Thank you COlumbo, that's exactly what I was looking for!

For the second part, how can I find out if my GPU's memory is already saturated?

Thanks

Thank you for the clarification L. Spiro, which actually confuses me a little bit ;)

Take texture memory. Does that mean that if you try to put too many textures onto the GPU, some textures will automatically be flushed? If yes, then this means I might have to upload textures more than one time!?

I somehow feel that texure memory is yet another story. But take VBOs: I creating them via Qt, like:

QGLBuffer* myVBO=new QGLBuffer(QGLBuffer::VertexBuffer);
myVBO->create();
myVBO->bind();
myVBO->setUsagePattern(QGLBuffer::StaticDraw);
myVBO->allocate(vertices,3*verticesCnt*sizeof(float));

and everytime, in order to use them, I call:

myVBO->bind();
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3,GL_FLOAT,0,0);
glDrawArrays(GL_TRIANGLES,0,verticesCnt);
glDisableClientState(GL_VERTEX_ARRAY);

And that works fine. I never have to upload the vertices to the GPU again. So is there something that happens behind the scene?

Thanks

GPU Memory management shouldn't be treated any differently that CPU memory management. If the driver virtualize the memory and handling flushing on overcomit, thats great, but does that mean one should do it? The major graphics API provide means to check out of memory situation, though reactive instead of pro-active, its better than nothing. Properly design software should check these conditions and react accordingly. Also, just to clarify memory is memory wrt to the GPU, there is no separate texture memory, VBO, FBO, IBO memory. To the driver, they are just a block of memory with semantics attached to them( covering usage, access etc ).
In the example you gave above, the memory is allocated by the driver and there is no need to upload anything else unless you are changing the content of the memory. The binding call and the client state setup is just telling the driver that all subsequent draw call will use the bounded buffer as the source for vertex data. There is no upload taking place in this case.

I guess the most important question is are you running on a memory constraint hw for you to be worried about running out of memory for such small amount of vertex data ?

Interesting, thanks to both of you!

So what about following strategy:

I keep track of all textures and VBOs that I have registered with the GPU. If I notice that I am coming close to a saturation, then I release a few textures or VBOs that were not used for a while... (e.g. not used because out of sight). Does that sound reasonable?