CODEWITHSUNDEEP
javac++opengl3d
Allahjane
Allahjane

Reputation: 1978

Frame Rate and draw flow in openGL

I cannot seem to understand how the frame drawing sync with buffer swapping.

Following are the questions:

1.Since most of the open GL calls are non blocking (or buffered) how do you know if the gpu is done with current frame?

2.Does open GL handles it so that an unfinished frame wont get swapped to the window buffer

3.How do you calculate the frame rate? I mean what is the basis for determining the no of frames drawn or time taken by each frame?

Upvotes: 1

Views: 2078

Answers (3)

Reto Koradi
Reto Koradi

Reputation: 54592

  1. Generally, you don't. And I can't think of a very good reason why you should ever worry about it in a real application. If you really have to know, using sync objects (as already suggested in the answer by @derhass) is your best option in modern OpenGL. But you should make sure that you have a clear understanding of why you need it, because it seems unusual to me.
  2. Yes. While the processing of calls in OpenGL is mostly asynchronous, the sequence of calls is still maintained. So if you make a SwapBuffers call, it will guarantee that all the calls you made before the SwapBuffers call will have completed before the buffers are swapped.
  3. There's no good easy way to measure the time used for a single frame. The most practical approach is that you render for a sufficiently long time (at least a few seconds seems reasonable). You count the number of frames you rendered during this time, and the elapsed wall clock time. Then divide number of frames by the time taken to get a frame rate.

Some of the above is slightly simplified, because this opens up some areas that could be very broad. For example, you can use timer queries to measure how long the GPU takes to process a given frame. But you have to be careful about the conclusions you draw from it.

As a hypothetical example, say you render at 60 fps, limited by vsync. You put a timer query on a frame, and it tells you that the GPU spent 15 ms to render the frame. Does this mean that you were right at the limit of being able to maintain 60 fps? And making your rendering/content more complex would drop it below 60 fps? Not necessarily. Unless you also tracked the GPU clock frequency, you don't know if the GPU really ran at its limit. Power management might have reduced the frequency/voltage to the level necessary to process the current workload. And if you give it more work, it might be able to handle it just fine, and still run at 60 fps.

Upvotes: 1

derhass
derhass

Reputation: 45332

The modern way of syncing with the GL is using sync objects. Using glFinish() (or other blocking GL calls) has the disadvantage of stalling both the GPU and the CPU (thread): the CPU will wait until the GPU is finished, and the GPU then stalls because there is no new work queued up. If sync objects are used properly, both can be completely avoided.

You just insert a fence sync into the GL command stream at any point you are interested an, and later can check if all commands before it are completed, or you can wait for the completion (while you still can have further commands queued up).

Note that for frame rate estimation, you don't need any explicit means of synchronization. Just using SwapBuffers() is sufficient. The gpu might queue up a few frames in advance (the nvidia driver has even a setting for this), but this won't disturb fps counting, since only the first n frames are queued up. Just count the number of SwapBuffer() calls issued each second, and you will do fine. If the user has enabled sync to vblank, the frame rate will be limited to the refresh rate of the monitor, and no tearing will appear.

If you need more detailed GPU timing statistics (but for a frame rate counter, you don't), you should have a look at timer queries.

Upvotes: 2

karlphillip
karlphillip

Reputation: 93410

  • Question 1 and 2: Invoke glFinish() instead of glFlush():

Description

glFinish does not return until the effects of all previously called GL commands are complete. Such effects include all changes to GL state, all changes to connection state, and all changes to the frame buffer contents.

  • Question 3: Start a Timer and count how many calls to glFinish() were executed within one second.

Upvotes: 1

Related Questions