What is the max size of one vertex-buffer?
I tried to make one Buffer > 250k vertices and the rendering was wrong. Not an issue for me really as I have several smaller buffers, but makes me wondering as it worked with a normal VA.
How much memory can I acces by using VBO?
Will it give me normal system memory when AGP memory is full or will it simply refuse to give anything?
My point is: It would be nice if I wouldn’t have to check wether my buffer allocation worked and choose a different path if not.
(The question could be: Am I limited to some video memory with VBO or to system memory?)
Depends on the video card and the amount of video RAM. ATI cards with 128 MB of video RAM are limited by the drivers to a maximum of 32 MB per vertex buffer. With multiple buffers the total can easily go beyond 32 MB with no problem, but I haven’t tried to find a cap.
Well, personally I think that when you run out of video memory it should be stored in system memory. However, whether the drivers actually do that or not. . . I really have no idea.
Originally posted by Ostsol: Well, personally I think that when you run out of video memory it should be stored in system memory. However, whether the drivers actually do that or not. . . I really have no idea.
I’m not sure, because it wouldn’t be effective.
If there isn’t enough graphics memory then the driver might give an OUT_OF_MEMORY error.
After that you can use the simple vertex pointer method.
If you think it’s faster because the driver don’t need to copy the whole array to a new place (and of course don’t need to allocate more memory).
Originally posted by Csiki: I’m not sure, because it wouldn’t be effective.
If there isn’t enough graphics memory then the driver might give an OUT_OF_MEMORY error.
After that you can use the simple vertex pointer method.
True, but that would require implementing such a contingency. Would it not be better for VBO to automatically switch to AGP memory so that such a contingency would not have to be specifically coded for? Is this not the way it works with textures?
Technically, the spec does allow an implementation to generate GL_OUT_OF_MEMORY if it runs out of graphics memory.
Practically, no reasonable VBO implementation should do this, because it makes VBO worthless in my opinion. VBOs should be managed the same way textures are managed: each of them should be small enough to fit in graphics memory, but if all of them combined don’t fit, they should spill over into system memory.
This doesn’t force the driver to do anything – in the worst case scenario it simply has to do exactly what you would do yourself if you weren’t using VBO at all: draw the vertex array out of system memory. Why would the driver writers want to force every VBO user on the planet to write a fallback for the OUT_OF_MEMORY case if they can provide the fallback themselves?
Originally posted by Ostsol:
[b] [quote]Originally posted by Csiki: I’m not sure, because it wouldn’t be effective.
If there isn’t enough graphics memory then the driver might give an OUT_OF_MEMORY error.
After that you can use the simple vertex pointer method.
True, but that would require implementing such a contingency. Would it not be better for VBO to automatically switch to AGP memory so that such a contingency would not have to be specifically coded for? Is this not the way it works with textures?[/b][/QUOTE]
In general it would be good.
But the specification doesn’t write anything about this and the driver might do what I wrote.
It would be good to make more precise the spec (that the VBO is system or graphics memory limited).
I don’t know what the ATI and NVIDIA drivers do in such cases.
Have anybody some tests?
Originally posted by Tom Nuydens:
[b]Both ATI (since Catalyst 3.6) and NVIDIA do the fallback automatically – including the one to system memory if necessary.
– Tom[/b]
Ah, thanks for the clarification, thats what I wanted to hear!
