pouët.net

Slow vertex arrays?

category: general [glöplog]
i'd like to see optimus switch over to VBOs and measure the difference. all cache and copying costs aside, i wouldn't be surprised if non-VBO glDrawArrays simply wasn't optimized at all on current drivers, since it's rarely used.
added on the 2009-03-30 15:12:27 by ryg ryg
kb: this might be true to some extent, but not a 2x! you have to add the cost of a function call to the driver for every vertex, the bookkeeping in that call etc. unless the DrawArrays driver code is totally braindead (like just calling the vertex function n times) it really should be faster. Also stream copies are very optimized in current cpus, not that much difference to L1 there anymore.
nystep: the copy is done on the Draw call. I am not arguing that Draw + VertexPointer is fast, i am just saying that i do not see how it can be slower than glVertex calls. Also your example above with points probably is not going to gain from vbos vs. using VertexPointer because points will need some cpu processing to begin with.

Personally i love VertexPointer as it lets you write code quickly and change it easily later once it becomes a bottleneck.

I stand by my theory that Optimus is doing bad measuring or that the ATI driver in question sucks badly. :)
added on the 2009-03-30 15:18:19 by shiva shiva
Well, my random guess about this, is that the glVertex functions are staying in user mode so the calls are extremelly fast, and batching calls somehow have to switch to kernel mode to do stuff so it may be slower. Hard to verify anyway.
added on the 2009-03-30 15:33:26 by nystep nystep
I am pretty sure i had seen a topic about benching all the different ways to render geometry in opengl, on the opengl.org forums years back. unfortunatelly i cant find it :/ seems like the board is not keeping messages that are more than 5 years old. but i do remenber that everyone was also surpised that glVertex3f is so fast, faster than vertex arrays.
added on the 2009-03-30 15:45:35 by nystep nystep
you mean the OpenGL Geometry Benchmark 1.0 made by our colleague Flavien? It doesn't include VBO, but it's still a nice benchmark.
added on the 2009-03-30 17:48:00 by iq iq
reminds me of the tutorial that was supposed to show VBs in D3D were faster than DrawPrimitiveUP. It went like this:

- First, the example was a spinning cube. Yes, 8 vertices are the perfect benchmark
- Then, VSync was on. So much for ANY measuring ability.
- Then, the guy called Process() on the VB, which transformed the vertices in software
- Then without clearing the matrices he drew the VB and the matrices got applied AGAIN
-> The cube was spinning twice as fast as in the DPUP version, so OBVIOUSLY using vertex buffers is 100% FASTER!!!11one.

People. *sigh* :)

added on the 2009-03-30 17:54:45 by kb_ kb_
damn, the link was http://www.infinity-universe.com/opengl/GeomBench/

This one renders 768k tris, it should be more meaningful than a cube.
added on the 2009-03-30 17:59:28 by iq iq
it was something else that was benching VBOs as well.. but his site is much more complete, nice page :) and there were lots of gfx cards tested.
added on the 2009-03-30 18:15:16 by nystep nystep
the statistics for each video card link seem broken though :/
added on the 2009-03-30 18:17:14 by nystep nystep
oops, I will tell him
added on the 2009-03-30 20:12:18 by iq iq
all that talk of benching here makes me wanna pop "pumping iron" into that vcr
added on the 2009-03-30 22:57:28 by superplek superplek
I tried the test in some geforce (from 7600 to 8800) and things were more normal, vertex arrays were twice fast from glvertex method, display lists were still in 500fps. Probably it's the shitty ATI here. I just tried to implement VBOs and it seems slower (300fps) but I am not sure yet because something goes wrong and I don't get exactly the polygons I want. I will try to find the bug later and bench again.
added on the 2009-03-30 23:27:58 by Optimus Optimus

login