I am using VBOs and it seems that OpenGL uses a lot more memory in creating these objects than expected. i assume this is because copies of the vertex data, etc. are maintained behind the scenes by OpenGL. Is there a way to tell OpenGL that it should not under any circumstance maintain anything in main memory? I am currently just setting the GL_STATIC_DRAW_ARB state for static meshes.
If you mean for the object that is held in the VBO to be static, you can remove the data you allocated after uploading to the VBO.
Take a look at the examples at the end of this and you will get it:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
It doesn’t look like something I could use, it is not an option to mix the creation of the VBOs with the rendering loop. I would like to create the objects somewhere else and just tell OpenGL to keep it on the graphics card at all time and not create system copies
Create the VBOs before you render, in something like an init()-function. When you’ve created the VBOs you will call them by indices, very much like you would with a display list aswell.
Some more links:
http://www.idevgames.com/forum/showthread.php?t=10835
http://www.gamedev.net/community/forums/topic.asp?topic_id=336689
I believe this is not what bowman had in mind.
OpenGL support in Windows drivers MUST keep everything passed to GPU in system memory - this is actually Windows fault.
In DirectX there is an error that tells an application that resource it refers to no longer exists on GPU (it was removed by system). In OpenGL there is no such error message, because it should not be our problem that system removed something from GPU.
For this reason OpenGL drivers keep everything backed-up in system memory and upload resources again if they’re lost.
Windows could actually tell the driver that some resource needs to be removed from GPU. This way driver could download this resource from GPU and create it’s duplicate in system memory. Unfortunately Windows removes resources on it’s own and the driver can only get that information after resource is allready gone.
What I was referring to was the fact that once you have passed the data to your buffer it will be kept there (I don’t know exactly where this buffer is physically but I assume it is in some fast memory on the motherboard).
After reading bowman’s post again I am a bit confused. How is it possible to measure how much memory OpenGL uses to create these objects? I have never heard of such a query, but that obviously doesn’t mean that it doesn’t exist. It may of course be done by checking system memory and figuring out exactly what was allocated where and then assuming that OpenGL accounts for the rest.
I see know that I wasn’t really answering bowman’s question at all… sorry about that!
thinks,
VBO comes with glGetBufferParameterivARB() to measure the size of VBO.
int bufferSize;
glGetBufferParameterivARB(GL_ARRAY_BUFFER_ARB, GL_BUFFER_SIZE_ARB, &bufferSize);
Did you mean the above function or something else?
You can see how much RAM your system is using by looking at task manager, which is said not to be reliable but I think it is an indicator.
k_szczech is right, the driver needs to put asside everthing in RAM or hard drive.
“Is there a way to tell OpenGL that it should not under any circumstance maintain anything in main memory?”
No
By the way - does Linux habve this drawback? I’m planning to port my framework to Linux soon, s I’m going to find out anyway, but I’m curious.
I have used task manager as an indicator of how much memory is used. An example is a vertexbuffer, which i calculated would need about 17k for vertices. In the task manager I could see that about 84k actually was used, which seems like a lot more than needed. It seems that DirectX is more flexible, allowing the developer to specify more precisely how memory should be used (whether it should be system, AGP, etc.) and that OpenGL maintains a lot of things behind the scenes, which is out of the developers hands
Yes, D3D is more flexible but it comes at a cost. With D3D9 and lower, you need to check if you buffers and textures still exist before using them.
If you have a resizeable window, you need to take care of this as well. Destroy resources, destroy D3D and recreate all.
D3D10 will get rid of all of that nonsense.
If you have an nvidia card, you can use the old extension agp_allocate_memory_nv or so, which also allows you to choose between agp or system memory… but you wouldn’t be able to use vbo anymore I guess.
How does nvidia’s extension solve the problem?
Secondly, you have to be sure that NV is updating that old thing.
I didn’t said this solves the problem. He wanted ways to controlate where to allocate the memory of the arrays, so I made this suggestion, simply, and without any pretention or anything else.
From this: http://www.opengl.org/registry/specs/NV/vertex_array_range.txt
it doesn’t seem to be deprecated, even thought I don’t use it at all anymore, so I can’t be sure NV is updating it.