I use a CADisplayLink that fires a callback to my render code at a vsync locked 60fps.
That callback is part of an NSOpenGLView, which is (one of) OSX's mechanisms to providing an OpenGL window.
]flushBuffer[/url]] is called once you're done with your draw calls, it pretty much boils down to [glFlush + glSwapBuffers]
My understanding was
that flushBuffer blocks until the GPU has done its thing. As you say, timing GPU operations isn't particularly precise.. I'll say :)
I've basically got something like this going:
- (CVReturn)getFrameForTime:(const CVTimeStamp*)outputTime
// render here, vsync fired
static double frameStart;
static double lastFrameStart;
lastFrameStart = frameStart;
frameStart = getCurrentTime();
double frameInterval = frameStart - lastFrameStart;
render(); // render the scene, draw calls etc
double commandBufferTime = getCurrentTime() - frameStart;
[currentContext flushBuffer]; // rendering is done, flush and swap
double frameEnd = getCurrentTime();
double frameTime = frameEnd - frameStart;
Since this function only fires on the vsync, if frameInterval
is larger than 16.777 then I know I've missed a frame.
frameTime tells me the elapsed time in which all draw calls and the flushBuffer completed, which I would expect to be a reasonably useful measurement.
That said.. I'm looking a little closer at this
Even a 'swapbuffer' call can leave work for the graphics system to do that can hang around and slow down subsequent operations in a mysterious fashion. The cure for this is to put a 'glFinish' call before you start the clock as well as just before you stop the clock.
With the above in mind, it does indeed seem that a lot of the wait time is occurring after the swapbuffer call.
I suppose the best approach is to just, draw less.. but I seem to be facing an LOD conundrum. The whole idea of LOD is to use less detailed mesh for further away objects, and higher detailed meshes for those that are closer. But it seems to be those high detailed meshes that give me performance issues at close range.
It's not really a problem, these are exaggerated meshes that I'm using to help my understanding of the potential bottlenecks, and how they manifest.. I'm just seem unable to draw many conclusions from it :)