Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


OpenGL Frame Rate


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 S1G   Members   -  Reputation: 143

Like
0Likes
Like

Posted 21 September 2009 - 02:05 PM

At the moment, my OpenGL application as a whole is running at 60 hz, which is my screen's refresh rate. After a render has occured, I believe that my program is sleeping until a 1 / 60 time frame has occured since the beginning of the render. Is there anyway to tell OpenGL not to sleep after a render? I think that I might need to thread the OpenGL component of my program so that it does not lag the rest of the program. Any ideas?

Sponsor:

#2 HuntsMan   Members   -  Reputation: 368

Like
0Likes
Like

Posted 21 September 2009 - 02:30 PM

You need to disable VSync, which does exactly that. But first, find out why is it enabled, you might forcibly enabled it in your display drivers configuration, or your graphics API (not OpenGL, the one that creates the window) is doing it.

#3 NumberXaero   Prime Members   -  Reputation: 1520

Like
0Likes
Like

Posted 21 September 2009 - 03:05 PM

Look up the extension that provides wglSwapIntervalEXT(0) (windows).

#4 S1G   Members   -  Reputation: 143

Like
0Likes
Like

Posted 21 September 2009 - 04:34 PM

I tried using wglSwapIntervalEXT but I'm not convinced that this is the problem. I can't tell if it is OpenGL or the WIN32 API that's capping my frame rate at 60 hz.

#5 idinev   Members   -  Reputation: 236

Like
0Likes
Like

Posted 21 September 2009 - 04:42 PM

Then you've forced vsync-on in your driver's control-panel. Restore it to "application preference".

#6 Trienco   Crossbones+   -  Reputation: 2224

Like
0Likes
Like

Posted 21 September 2009 - 05:41 PM

Quote:
Original post by Sigvatr
Is there anyway to tell OpenGL not to sleep after a render? I think that I might need to thread the OpenGL component of my program so that it does not lag the rest of the program.


It's not sleeping after a thread, it is blocking when you call swapbuffer, because with vsync it has to wait for the monitor to finish. Sure you can disable that for testing or benchmarking, but at 1000fps you end up with seeing 16 horizontal stripes of 16 different frames because you swap out the framebuffer right under the monitors a.. backside.

Ask yourself, which parts of your program ever _need_ to make more than 60 updates a second (running "as fast as possible" just generates heat and on certain graphic cards like mine, a seriously annoying high pitched whine).

If you do have some, then the answer is pretty simple and obvious: don't render a frame on every loop.

#7 S1G   Members   -  Reputation: 143

Like
0Likes
Like

Posted 21 September 2009 - 08:24 PM

Yeah, I'm going to thread my code so I don't swap back buffers until an entire new one is completed rendering, so I can do manual a Vsync and have the rest of my game code in it's own thread.

#8 samoth   Crossbones+   -  Reputation: 5036

Like
0Likes
Like

Posted 21 September 2009 - 11:21 PM

Quote:
Original post by Sigvatr
Yeah, I'm going to thread my code so I don't swap back buffers until an entire new one is completed rendering, so I can do manual a Vsync and have the rest of my game code in it's own thread.
Adding threads is fine, but not for this case. Rendering the next frame in a different thread is not only a logistic/management disaster, it also requires you to MakeCurrent your context. Switching contexts is not just expensive, it is suprisingly expensive at times.

If you throw threads at your application, you will want to run other things (physics, pathfinding, ...) in a different thread, but keep the rendering constrained to the thread that created the context. Note that synchronising threads properly is non-trivial and may take a lot of care.

It is perfectly ok to block on VSYNC. The monitor won't be able to show more information than that either way, and less CPU cycles are burned.
Also do note that the driver may let you render 2-3 frames ahead before blocking you. You have no guarantee that what you think is the current frame is really the one on the screen. Or the next one, for that matter.

#9 Fiddler   Members   -  Reputation: 856

Like
0Likes
Like

Posted 22 September 2009 - 01:05 AM

Many drivers block at the next OpenGL command you issue after a vsynced SwapBuffer. For all intents and purposes, there is no difference between a blocking SwapBuffers and this "semi-blocking" version - with one exception: you can add non-OpenGL code after a SwapBuffers and reduce the chance of a block. This way you can improve performance "for free".

(Note: this is orthogonal to the drivers rendering 2 or 3 frames ahead! Besides, you have no control of double- or triple-buffering in OpenGL.)

[OpenTK: C# OpenGL 4.4, OpenGL ES 3.0 and OpenAL 1.1. Now with Linux/KMS support!]


#10 S1G   Members   -  Reputation: 143

Like
0Likes
Like

Posted 22 September 2009 - 04:18 PM

I was able to disabled Vsync through my NVidia control panel, but only if it is force to be off by default. If I let the application decide, then my app runs with Vsync on by default.

How do I disable this? wglSwapIntervalEXT(0) hasn't been working, or maybe I'm putting it in the wrong place.

#11 NumberXaero   Prime Members   -  Reputation: 1520

Like
0Likes
Like

Posted 22 September 2009 - 04:41 PM

I call it once at initialization, after all extension have been loaded. Its actually the first thing i call.

#12 ma_hty   Members   -  Reputation: 100

Like
0Likes
Like

Posted 23 September 2009 - 09:47 AM

Quote:
Original post by Sigvatr
Yeah, I'm going to thread my code so I don't swap back buffers until an entire new one is completed rendering, so I can do manual a Vsync and have the rest of my game code in it's own thread.


Using different threads for logic routine and graphics routine is the right way to go. However, you shouldn't turn off Vsync if you are using this approach. Instead, you should leave Vsync enabled.

Just in case you doesn't notice. if your program behaves correctly, its window will not be redrew unless a portion of the window is changing from invisible state to visible state or you tell it to do so explicitly. So, if you don't want the window to be redrew, you just need to stop firing redraw command.

Turning off Vsync is only useful for the lazy guy who want to implement both logic routine and graphics routine within a single thread. However, the flaws of this lazy approach is simply too obvious to be tolerated. (At least, I won't forgive.)

#13 ma_hty   Members   -  Reputation: 100

Like
0Likes
Like

Posted 23 September 2009 - 07:54 PM

Quote:
Original post by Trienco
... Sure you can disable that for testing or benchmarking, but at 1000fps you end up with seeing 16 horizontal stripes of 16 different frames because you swap out the framebuffer right under the monitors a.. backside. ...


It is incorrect to measure framerate (benchmarking) by simply turn off Vsync. The framerate measured this way didn't not take into account the more demanding graphics operation.

Lets put it this way. The OpenGL command you called would not be executed immediately at the time you call it. Instead, it is buffered. If you try to test the framerate by simply turn off Vsync, you measure the time taken to upload the OpenGL command to the buffer only. You can verity this problem very easily. You draw a full screen quad with Vsync ON and do something fancy in the fragment shader which lowered the framerate well below 60 fps. Afterward, you turn off Vsync and measure the framerate again. You will find that the lateral case took no time to complete, which is simply not reflecting the fact at all.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS