4/7/24, 4:14 PM java - Frame Rate and draw flow in openGL - Stack Overflow

Frame Rate and draw flow in openGL

Asked 9 years, 3 months ago Modified 9 years, 3 months ago Viewed 2k times

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

Following are the questions:

1
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?

java c++ opengl 3d

Share Improve this question Follow edited Dec 25, 2014 at 13:01 asked Dec 25, 2014 at 12:41
Allahjane
1,938 3 24 43

Relevant: stackoverflow.com/a/24136893/524368 – datenwolf Dec 25, 2014 at 14:09

@datenwolf Exactly! Excellent point – Allahjane Dec 25, 2014 at 15:43

3 Answers Sorted by: Highest score (default)

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
2 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.

Share Improve this answer Follow answered Dec 25, 2014 at 14:12

https://stackoverflow.com/questions/27647285/frame-rate-and-draw-flow-in-opengl?rq=3 1/3
4/7/24, 4:14 PM java - Frame Rate and draw flow in openGL - Stack Overflow
derhass
44.7k 3 64 85

I need to expand this to another question – Allahjane Dec 25, 2014 at 14:30

So is finish call depreciated or discouraged? – Allahjane Dec 25, 2014 at 15:45

Also it looks like syncing the draw calls with program calculation is still a active topic and is not standardized
– Allahjane Dec 25, 2014 at 16:02

@Allahjane: glFinish() is not deprecated, it is still there in modern core profiles. But it should be used with
care. In a normal OpenGL program, one very rarely (and often never) needs it. One used to need it in multi-
threaded situations whith shared contexts, but sync objects are a better alternative for that, too. – derhass Dec 25,
2014 at 17:23

Right! stuff finally got into my head – Allahjane Dec 25, 2014 at 19:20

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

1 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.

Share Improve this answer Follow edited Jun 20, 2020 at 9:12 answered Dec 25, 2014 at 12:46
Community Bot karlphillip
1 1 92.7k 37 246 433

Err is that the standard method? I haven't seen any GL application code using glFinish or glFlush yet! or maybe its
just me – Allahjane Dec 25, 2014 at 12:53

As far as I can tell. I would love to see your answer on this. – karlphillip Dec 25, 2014 at 12:54

Also I need a bit more info on Q.2 please – Allahjane Dec 25, 2014 at 12:54

You would have to take a look at one of the implementations of OpenGL to be able to answer that question with the
level of detail you want. – karlphillip Dec 25, 2014 at 12:59

When you call glFinish() there's a guarantee that this function is only going to return after the frame was draw
successfully to the screen. So to answer question 2 again, YES. – karlphillip Dec 25, 2014 at 13:05

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
1 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.

https://stackoverflow.com/questions/27647285/frame-rate-and-draw-flow-in-opengl?rq=3 2/3
4/7/24, 4:14 PM java - Frame Rate and draw flow in openGL - Stack Overflow

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.

Share Improve this answer Follow answered Dec 25, 2014 at 18:41
Reto Koradi
54k 8 96 141

https://stackoverflow.com/questions/27647285/frame-rate-and-draw-flow-in-opengl?rq=3 3/3