Debugging GPU frame

Im trying to make my app more efficient in it’s drawing.
Xcode has this GPU debugger, should i listen to this? and can i do anything about it in oF?
thanks

Hi @Miles!

Yes, these are all very good recommendations, provided you are rendering on a mobile GPU. Items referring to ‘tiling’ suggest this is the case.

When you optimise for the GPU there is a trade-off (like in any optimisation challenge) between having a general solution that works on any hardware and a perfect optimised solution that works on specific hardware.

The programmable GL renderer in openFrameworks attempts to provide sensible defaults, and a general approach, which, in tandem with the GPU driver, should give good performance for most general cases.

If you want to get the most out of your specific hardware, then it’s worth looking into which methods of your draw call use the most of the frame time, and optimise these.

One of my favourites with openFrameworks and OpenGL is that you have always the option to “drop down” to the next lower level and issue ‘pure’ OpenGL API calls. If you do so, it’s worth keeping in mind that OpenGL is a giant state machine, and that any state that your OpenGL calls touch (like blend mode, or depth testing, or triangle winding order etc) might need to be somehow returned to some setting that will not lead to unwelcome surprises later on in your program flow. What I tend to do is that I set values back to openGL defaults when I issue pure OpenGL calls.

Before dropping down all the way to OpenGL it’s often a good idea to make sure you make the most use of openFrameworks methods, because these could be easier winnings:

  • use ofVboMesh for meshes that you load once, and then only use for rendering, and tell oF to use STATIC_DRAW for the ofVboMesh
  • try to render multiple meshes which use the same shader together (if possible, bind the same shader only once)
  • try to minimise the number of if-then clauses in your (fragment) shader(s)
  • try to minimise blending mode changes by grouping (for example, first draw all elements that need alpha blending, then draw all elements that use screen blending) if that’s possible and won’t change what in the end needs to be drawn by your app.
  • try to minimise overdraw: when you draw with depth-testing, draw the objects closest to the camera first, so that blending doesn’t have to run for elements which are hidden anyway by elements sitting in front of them.

There are things where some targeted OpenGL calls can do wonder, sometimes.

  • with a mobile GPU it can also help if vertex data is interleaved (that’s what the “Perfromance limited by Tiling” section refers to), because then all the data for a triangle is as close together as possible (when using a default ofVboMesh, the vertex buffers are serialized, so you have one buffer that has positions, then colors, then normals, possibly). But you can upload a VBO manually with interleaved attributes using OpenGL api calls.

Good luck! =)

2 Likes

you are a superstar! thank you very much. Ill experiment based on your recommendations and report back!
thanks again,
Miles