Jump to content
  • Advertisement
Sign in to follow this  
Prune

Triple buffering and energy efficiency

This topic is 3751 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Using no VSYNC is a problem for me because then the graphics card is always working at maximum trying to render as fast as possible. As I'm at the same time concerned about efficiency (due to severe electrical restrictions in a multi-PC unit), yet be able to when needed have high performance (and thus not going simply with a lower power card), so I need to use VSYNC for that alone. However, the frame rate fractioning is a problem especially with the low refresh rate on an LCD display. So I'm considering triple buffering. But I'm not clear on something about it: if buffer A is being displayed, and the card finishes drawing in both buffers B and then C early, will it then go back to rendering in B? If so, then this is wasteful like the no-VSYNC situation and frames are being thrown away without drawing them--power that could've been saved. So is this how the behavior is set up, or will the graphics driver wait after it fills the two non-displaying buffers? I guess my goal is to avoid both a) getting the halving of frame rate when it drops even a bit below the refresh rate, and b) wasting power by drawing faster than the refresh rate. By the way, I assume in the NVIDA control panel that turning on triple buffering doesn't internally switch on VSYNC and that must still be turned on separately?

Share this post


Link to post
Share on other sites
Advertisement
I'll be following this thread as I have similar interests.

On a side note, put a Sleep(1); in your main loop. Does that help your energy requirements on your system? (when vSync is disabled)

Share this post


Link to post
Share on other sites
Something weird... I was using RivaTuner's video memory plugin in the hardware monitor to check if there was any difference in memory use. The expected increase of four bytes times pixels only showed up if in NVIDIA's control panel both VSync and triple buffering are turned on. If only triple buffering is enabled but not VSync, there's no memory use increase. So it seems enabling triple buffering doesn't necessarily enable it.

In my test program, framerate doesn't suffer the halving with VSync on when triple buffering is enabled (and I increase load so it's below the refresh rate), but does remain limited to the refresh rate (when I decrease the load), so whatever the SDL_SwapBuffers() implementation refers to the driver must be blocking. I'm going to do a power comparison (by proxy of the temperature graph) to make sure, but this seems to be what I was hoping for.

Share this post


Link to post
Share on other sites
Quote:
Original post by Prune
if buffer A is being displayed, and the card finishes drawing in both buffers B and then C early, will it then go back to rendering in B?


No. Think of frame buffering of this sort as a ring buffer. Rendering happens whenever there is an empty slot in the ring, and rendering a frame fills that slot. Displaying a new frame (as opposed to displaying the same frame as the last vsync tick) happens when there is a filled slot in the ring that is not the same as the frame currently being displayed, and moving to this new slot empties the old slot. So in your case, if you were displaying frame A, and managed to render frames B and C before the next vsync, the driver would then pause rendering because it wouldn't have any empty slot to render to. On the next vsync tick, the card would stop displaying from buffer A and start displaying buffer B. At that point, A would be empty, and the driver would render into A. At no time is a frame rendered without eventually being displayed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!