4
\$\begingroup\$

So, this seems odd to me. I upload a large buffer of vertices, then every frame I call glBindbuffer and then the appropriate gl*Pointer functions with offsets into the buffer, then I use glDrawArrays to draw all of my triangles.

I'm only drawing about 100K triangles, however I'm getting about 15FPS.

This is where it gets weird, if I change it to not call glBindBuffer, then change the gl*Pointer calls to be actual pointers into the array I have in system memory, and then call glDrawArrays the same, my framerate jumps up to about 50FPS.

Any idea what I weird thing I could be doing that would cause this? Did I maybe forget to call glEnable(GL_ALLOW_VBOS_TO_RUN_FAST) or something?

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
2
\$\begingroup\$

glBindBuffer is expensive, but not so much that you can expect a noticeable impact from a single bind (or several dozen of them, for that matter).

Did you check that you have the right usage flags when creating the buffer storage with glBufferData? For your scenario, GL_STATIC_DRAW is the ALLOW_IT_TO_RUN_FAST flag. If you accidentially use the wrong flags, it might do silly things with your buffer.

I've seen performance drop of nearly two full frames worth on a readback into a PBO once only because I used the wrong flags. When you get that one wrong, it is a "wtf, this cannot possibly take 30 ms???" experience.

Improve this answer
\$\endgroup\$
10
  • 1
    \$\begingroup\$ Yeah, I'm using GL_Static_Draw, that's the sort of thing I thought it might be however. \$\endgroup\$
    – Arelius
    Mar 11, 2011 at 23:05
  • \$\begingroup\$ A buffer holding 100k triangles, resp. 300k vertices should be no challenge to a somewhat modern graphics card, but ... what does glGet say on GL_MAX_ELEMENTS_VERTICES? I assume you're checking glGetError as standard procedure too? \$\endgroup\$
    – dm.skt
    Mar 11, 2011 at 23:19
  • \$\begingroup\$ 2048? I am also checking glGetError. \$\endgroup\$
    – Arelius
    Mar 11, 2011 at 23:29
  • \$\begingroup\$ Doesn't that seem awfully small? This is on an i7 MacBook Pro, It's supposed to have nvidia graphics. \$\endgroup\$
    – Arelius
    Mar 11, 2011 at 23:36
  • 1
    \$\begingroup\$ Just googling around, I found this which seems to be a printout of the 330M (the discrete graphics in the 2010 MacBook Pro) and it says "GL_MAX_ELEMENTS_VERTICES: 1048576". Try installing gfxCardStatus and make sure your discrete card is being used and not the integrated Intel chip; that might actually explain the system memory being faster too, since the integrated chip leeches off of system memory (I think) and should therefore have fast access to it... \$\endgroup\$
    – Ricket
    Mar 14, 2011 at 13:08
1
\$\begingroup\$

I think its a code specific problem not problem with VBOs..

  • make sure you are not copying VBOs every time.
  • make sure you are not misusing VBOs functions (I think there is a small difference between using VBOs in openGL 3.0 and previous versions).
  • make sure that openGL is not generating an Error.
  • debug your openGL code using gDebugger.
Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Copy them once, Additionally the code that runs to upload them is still getting uploaded, they are just going unused. I've been debugging with gDebugger, no warnings or errors. \$\endgroup\$
    – Arelius
    Mar 11, 2011 at 22:33
  • \$\begingroup\$ Look at the stats generated by gDebugger too - you may be doing something weird by mistake. \$\endgroup\$
    – Jari Komppa
    Mar 14, 2011 at 13:59
  • \$\begingroup\$ @Jari, nothing obvious. \$\endgroup\$
    – Arelius
    Mar 14, 2011 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .