ati's drivers... and vertex buffer objects (opengl)

[Dio]

From my point of view: a VBO that is only used once and then deallocated (i.e. the same buffer name is used again with a different size) will not be an optimisation because this causes extra cycles to be spent on memory management, and highly likely the fragmentation of video or AGP memory. As a result, if we haven't optimised specifically for this case it's most likely because there are lower overhead ways of doing the same thing.

However, I'd strongly suggest he contact our devrel department, who can give much more informed and authoritative advice than I can. They can both help improve usage of our chips and get formal performance issues filed against our drivers.

 

[Ostsol]

One thing I'm wondering: is he using the same buffer names for all meshes? Using glBufferData, wouldn't that cause major problems with buffers being resized constantly? Since I don't have Quake 2, I certainly can't test the thing to find out. . .

 

[Dio]

Originally posted by Berserk
I would like to hear the reasons why VBOs can't and/or shouldn't be used for dynamic geometry.
If not, then I'd like to know what path would be the fastest for Radeon hardware to directly compare it with my current approach that (one more time) is on par with CVAs performance wise on NVidia hardware.

I've had a think about this and come up with a methodology that should give identical performance to CVA on our hardware with minimal changes:

1. Allocate (with glBufferData) several buffer objects at initialisation time. Make these large enough for any data that will go into them. Mark them DYNAMIC (although actually this last shouldn't matter much it is best to give the correct hints).

2. Instead of using glBufferData to upload, use glBufferSubData.

This method is pretty much identical to the existing except it skips the memory management overhead. If it doesn't have CVA-level performance then I would suspect a bug and devrel definitely need to take a look at it. Hopefully this also demonstrates that dynamic geometry isn't any kind of problem.

 

[Rodéric]

1. Allocate (with glBufferData) several buffer objects at initialisation time. Make these large enough for any data that will go into them. Mark them DYNAMIC (although actually this last shouldn't matter much it is best to give the correct hints).

2. Instead of using glBufferData to upload, use glBufferSubData.

Nothing new in this, except the DYNAMIC thing which is cool because my BufferObject manager just build an array of VBO @ engine init and flag them all as DYNAMIC.
Do you know where DYNAMIC are likely to end up ? I expect VRAM...
(or hope maybe )

 

[Dio]

Well, buffer objects are just like textures. They could be in the swapfile until they're required if memory's filling up...