16

The title says everything, but just to be clear I'll add some extra words.

In this case, resize means:

  • getting more storage space at the end of the old vbo
  • saving the old data at the front
  • (hopefully not copying, but at least not on CPU side, meaning the driver should handle this)

EDIT

As to explain some more details and justify my question:
I will store data of (in forehand) unknown size to the VBO but I only know an upper limit that is a very rough estimation (10 - 100x as much or even more in unusual conditions).

Of course I know how much data I stored, when I am done with it, so it would be nice to store data until I find my VBO too small and resize it and then go on storing.

Here is why I don't want to copy(especially not on CPU side):
I am doing all this on the GPU to get interactive frame rates. When I have to copy it is very slow or even not possible, because there is not enough space. Worst of all is to copy the data over the CPU, hence passing everything over the bus, into a new memory region that has sufficient size, then glBufferDataing the VBO with new size and the new memory region as source. That would be the performance killer.

circumvented

I circumvented the problem with an exact estimation of the needed space. But I will let this question be unanswered for a week to see if someone has another hint on this as I am not very happy with the solution.

arkon
  • 2,209
  • 3
  • 27
  • 36
Nobody moving away from SE
  • 9,347
  • 3
  • 45
  • 92
  • are you trying to use only one (and huge) VBO? – Rookie Aug 31 '11 at 14:15
  • @Rookie: I want to hold the VBO as small as possible but still it can be huge(>100mb). But I want to store at least 3 of them in parallel and some extra data that are about 40mb size. – Nobody moving away from SE Aug 31 '11 at 14:19
  • 2
    Im not sure how VBO's performance varies between different cards, **but** on my card i can make max 1MB VBO or i lose performance a lot. Thinking about 100MB VBO sounds crazy. Try to split them into max 1MB pieces, i dont think you will render anything slower even if theres 100x more VBO's (which will be in your case only 300 VBO's). this should solve your resizing problem too. not to mention: in my card i CANT make larger than 4MB or something, after that the data gets corrupted and doesnt render the rest of it. – Rookie Aug 31 '11 at 14:22
  • @Rookie: For me those big VBOs are not a problem, they render fine with no corrupted data or slowdown. How old is your card? I think it is much more overhead to call 300 times glDrawArrays than to call it once on a big VBO but I did not test this. – Nobody moving away from SE Aug 31 '11 at 14:36
  • If you didnt test it, you should... maybe your card is just so fast that you think there is no slowdown even when you get only 1% of performance ;) my card isnt the best on market, but its pretty good, any game works just fine with it. if you do this thing only for yourself, then it doesnt matter if others cant run your program, otherwise you should run lots of tests how it performs on different users, i dont think i would be able to run that thing, might even blow up my card... ;) – Rookie Aug 31 '11 at 14:39
  • calling 300 times a VBO isnt the real bottleneck, think of it as drawing 300 objects on the screen: is 300 objects too much? hell no! i would say you might see a difference after 50000 VBO calls (i tested this too, and i actually never noticed almost any difference in FPS...) however, you better test these yourself since you (or the GFX card type you use) seem to be the only one using the program. – Rookie Aug 31 '11 at 14:43

3 Answers3

9

Revisiting this question after some years, the landscape has changed a bit with newer versions and extensions.

GPU Side Copying

The extension mentioned in Christian Rau's answer is core since 3.1 which allows us to copy contents (via glCopyBufferSubData) from one VBO to another. Hopefully, the driver does this on the GPU side!

Using this function we could create a larger buffer and copy the leading data over. This has the disadvantage of doubling the memory requirements because we need both buffers.

True resizing

The good news is: With sparse buffers an even better solution is on the horizon.

Given this extension we can allocate a virtual buffer with more than enough space for our data without ever paying for the unneeded space. We only have to "commit" the regions of memory we physically want to store data in. This means we can "grow" the VBO by committing new pages at the end of it.

The bad news is: As of the current OpenGL version (4.5) this is still an extension and not yet core, so adopting this might not be possible. You should also not that there are some details in the specification that are not yet worked out. For example, mapping of sparse buffers is disallowed in the current extension but support might be added in future versions.

I would be keen to hear about the availability of this extension if you have any data on that.

Nobody moving away from SE
  • 9,347
  • 3
  • 45
  • 92
9

I think without doing a copy you won't get around this, because the only way to resize a buffer is to call glBufferData and there is IMO no way to tell the driver to keep the old data.

What you probably can do to at least not copy it to the CPU and back again, is creating some kind of auxiliary VBO for these purposes and copy directly from the VBO into the auxiliary VBO (using the ARB_copy_buffer extension), resize the VBO and copy its contents back.

But I think the best way is just to allocate a larger buffer beforehand, so the resize is not neccessary, but of course in this case you need to know approximately how much extra storage you need.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
  • 6
    If you need a dynamical resizing VBO you can try to emulate the behaviour of `std::vector` and get armortized constant time when adding elements. – pmr Aug 31 '11 at 12:28
  • I also thought about that but the GPU memory (1GB) has heavy loads on it so there won't be much space left for holding an extra copy. I remember reading of the resize depending on the implementation. The driver *can* resize but it is not required to. Btw. greetings to ~rauc ;) – Nobody moving away from SE Aug 31 '11 at 12:45
  • I forgot about the large buffer: I have to allocate the buffer for data I do not know but can only estimate. The estimation gives me an allocation size that is ~100x greater than needed but I cant tell before. So in this case I will also have to resize (downscale) to not waste that much memory, which is rare as I already stated. – Nobody moving away from SE Aug 31 '11 at 12:46
-2

Assuming you have support for a recent OpenGL standard, an alternative to VBOs might be to store your data in textures ( again, assuming you have enough memory on your card ). Copying data between old and new textures would take place on the card and not affect the data transfer.

Exactly how you achieve this depends on exactly what your code is doing. But in principle, you use texture data to overwrite dummy vertex data in your drawing calls, or maybe use instancing. It would require a lot of thought and rework.

Roger Barrett
  • 1