Tested this on Radeon 9700 Cat 3.5. The VBO version runs very slow( 0fps when I press the ‘f’ key ), the non-VBO is quite fast ( 35fps ). The output seems messed up in both versions. Parts of the teapot is missing.
I havent tried that program yet, but im using vbo:s in my own programs on a radeon card ( and its been tested on gf4 and gffx aswell) and there we get a pretty nice preformance boost, so i wouldnt blame the drivers just yet.
I have made a app that uses VBO and on my HW i get very low FPS. I have a GForce 4 Ti 4600 with drivers 44.03.
[/b]
Hi Anders,
I implemented a VBO path in the OSG a couple of weeks back and found up to 50% peformance boost on coarse grained high polygon models.
However, on models that were composed of then of thosands of small peices of geometry the peformance of VBO is slower than using display lists. I think this is largely down to OpenGL calling overhead swamping the gains from VBO. The use of extensions and having to querry for them at runttime makes doing lots of extension calls expensive
The drivers that I am using are Nvidia’s 43.63 release under Linux. Results will obviously vary on different drivers/OS’s/graphics hardware, but in general my findings have been positive, save crashes reported on Geforce2Gp laptops.
I get the scary feeling that my usage of shorts for vertex coordinates and mixing VertexAttrib with normal VertexPointer slows it down. In my other apps I also do get a gain but in this case it runs really messy. 10X slower !! How could I detect that using VBO is 10X slower on a HW ?? I mean… VBO should be faster in ANY case right ?
I get the scary feeling that my usage of shorts for vertex coordinates and mixing VertexAttrib with normal VertexPointer slows it down. In my other apps I also do get a gain but in this case it runs really messy. 10X slower !! How could I detect that using VBO is 10X slower on a HW ?? I mean… VBO should be faster in ANY case right ?[/b]
Eventually I’d hope VBO to efficient for all vertex formats supported by the hardware, but I think its still early days for the driver support. The spec mentions that float for vertex storage being optimized… cut and pasted from the vertex_buffer_object.txt :
2.8A.1 Vertex Arrays in Buffer Objects
--------------------------------------
Blocks of vertex array data may be stored in buffer objects with the
same format and layout options supported for client-side vertex
arrays. However, it is expected that GL implementations will (at
minimum) be optimized for data with all components represented as
floats, as well as for color data with components represented as
either floats or unsigned bytes.
Ok. Just found something VERY interesting. The stall occurs when I mix VBO rendering with normal vertex arrays. The moving lamp in the demo is rendered by normal vertex arrays. When I remove the lamp geometry, the FPS goes up to 65 FPS ??
Is it forbidden to mix vertex arrays and vertex buffer objects ???
Now, that’s strange. No, you’re allowed to mix and match as you please. I’ve done that myself with no problems ( vertices, texcoords with VBO, TS vectors using normal arrays ).
to enable the usage of “normal” vertex arrays ?[/b]
AFAIK yes, but you must resupply all pointers. The GL doesn’t maintain extra vertex, texcoord, etc pointers to kick in when you turn VBOs off.