Author Topic: vsync always on? (Read 10097 times)

miotatsu · « **on:** October 20, 2014, 10:01:09 am »

I have been playing around with game loops and physics. The other day, I added some debug statements to see how much time each frame of my game loop was taking. As expected, the results were in the 16ms range. However, I tried disabling vsync, and these results did not change. Clearly vsync was still occuring.

My system is as follows:

    $ inxi -SMG
    System: Host: c7 Kernel: 3.16.4-1-ARCH x86_64 (64 bit) Desktop: i3 4.8 Distro: Arch Linux 
    Machine: System: Google product: Parrot v: 1.0
    Mobo: N/A model: N/A Bios: coreboot v: 4.0-4744-gac16405-dirty date: 10/23/2013
    Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
    Display Server: X.Org 1.16.1 driver: intel Resolution: 1366x768@60.02hz
    GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.3.1

The SFML vsync test case is given below:

#include <chrono>
#include <iostream>
#include "SFML/Graphics.hpp"

int main()
{
    auto* window = new sf::RenderWindow(sf::VideoMode(640, 480), "test",
        sf::Style::Titlebar | sf::Style::Close);
    window->setVerticalSyncEnabled(true);
    auto firstTime = std::chrono::high_resolution_clock::now();
    while(window->isOpen())
    {
        //print frame timing
        {
            auto secondTime = std::chrono::high_resolution_clock::now();
            using dMsecs = std::chrono::duration<double, std::chrono::milliseconds::period>;
            auto elapsed = dMsecs(secondTime - firstTime);
            firstTime = secondTime;
            std::cout << elapsed.count() << '\n';
        }
        //event handler
        {
            sf::Event e;
            while(window->pollEvent(e))
            {
                if(e.type == sf::Event::EventType::Closed)
                    window->close();
            }
        }
        //render
        {
            window->clear();
            window->display();
        }
    }
}

I have another test case written with SDL2 for comparison:

#include <chrono>
#include <iostream>
#include "SDL2/SDL.h"

int main()
{
    SDL_Init(SDL_INIT_VIDEO);
    SDL_Window* window = SDL_CreateWindow("test", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, SDL_WINDOW_SHOWN);
    SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC );
    auto firstTime = std::chrono::high_resolution_clock::now();
    auto quit = false;
    while(!quit)
    {
        //print frame timing
        {
            auto secondTime = std::chrono::high_resolution_clock::now();
            using dMsecs = std::chrono::duration<double, std::chrono::milliseconds::period>;
            auto elapsed = dMsecs(secondTime - firstTime);
            firstTime = secondTime;
            std::cout << elapsed.count() << '\n';
        }
        //event handler
        {
            SDL_Event e;
            while(SDL_PollEvent(&e))
            {
                if(e.type == SDL_QUIT) quit = true;
            }
        }
        //render
        {
            SDL_RenderClear(renderer);
            SDL_RenderPresent(renderer);
        }
    }
}

SFML sample output, vsync on:

(click to show/hide)

SFML sample output, vsync off:

(click to show/hide)

SFML, window->display() commented out:

(click to show/hide)

SDL2, vsync on:

(click to show/hide)

SDL2, vsync off:

(click to show/hide)

If this is a driver issue, I don't understand why other libraries have vsync implementations that behave correctly on my system?
What is the difference in implementation between the two libraries causing this differing behaviour, and can it be resolved? How would I go about getting the correct behaviour with SFML?

binary1248 · « **Reply #1 on:** October 20, 2014, 10:38:00 am »

Can you paste the full output of the glxinfo command here for us please?

eXpl0it3r · « **Reply #2 on:** October 20, 2014, 10:46:20 am »

Relevant source code bits (just in case):
GlxContext.cpp
SDL_x11opengl.c

miotatsu · « **Reply #3 on:** October 20, 2014, 12:33:00 pm »

Quote from: binary1248 on October 20, 2014, 10:38:00 am

Can you paste the full output of the glxinfo command here for us please?

(click to show/hide)

binary1248 · « **Reply #4 on:** October 20, 2014, 01:10:15 pm »

Well... the extension SFML relies on is supported...

When you say "vsync always on", do you mean that it is on by default? Or do you mean that it is on even though you called a function to explicitly disable it? Unlike SDL, SFML doesn't automatically force it to be off if the developer doesn't specify it to be on. There is a state of "don't care" or "leave it as what it is" if you don't do anything. SDL on the other hand always sets it, no matter whether you care or not. If you haven't already, try explicitly disabling vsync in SFML and see if it gets disabled. Also, remember that it depends on the system your code is running on as well. Some might have vsync on by default, some not.

miotatsu · « **Reply #5 on:** October 20, 2014, 01:22:03 pm »

Well this is embarassing
Turns out setVerticalSyncEnabled(false) does the trick.
I had been simply commenting out setVerticalSyncEnabled(true), as I expected it to default off.
I'm surprised I didn't try that, thank you for the help. >.<;

edit: nevermind, I had the display call commented out. setVerticalSyncEnabled(false) does not turn off vsync for me!

dabbertorres · « **Reply #6 on:** October 20, 2014, 07:23:30 pm »

Try running vblank_mode=0 before calling your executable. So:
vblank_mode=0 ./myexecutable

You'll want to take a look here: http://stackoverflow.com/questions/17196117/disable-vertical-sync-for-glxgears

miotatsu · « **Reply #7 on:** October 20, 2014, 11:14:44 pm »

Quote from: dabbertorres on October 20, 2014, 07:23:30 pm

Try running vblank_mode=0 before calling your executable. So:
vblank_mode=0 ./myexecutable

This worked. If nothing else, that trick would be sufficient to test my applications without vsync, but I'm still left wondering why turning off vsync does not work for me from SFML itself.

binary1248 · « **Reply #8 on:** October 20, 2014, 11:28:44 pm »

Try changing "glXSwapIntervalSGI" in this line to "glXSwapIntervalMESA" or "glXSwapIntervalEXT" and build SFML and see if it works. Make sure to get rid of all traces of SFML that are currently on your system before doing this. If this "fix" works, it smells like another case of a broken driver.

dabbertorres · « **Reply #9 on:** October 20, 2014, 11:38:33 pm »

No, it means the driver has vsync on. He needs to go and disable it via the method shown in the second answer on the Stack Overflow page I linked.

So, as he is on Intel graphics, he needs to edit /etc/X11/xorg.conf.
Find the Driver "intel" line, and in that section, add
Option "SwapbuffersWait" "false".

binary1248 · « **Reply #10 on:** October 20, 2014, 11:51:37 pm »

If the driver is forcing vsync to be on, which I assume is what you meant, SDL wouldn't be able to disable it either. If it is on by default but can be disabled, SFML should be able to disable it when he calls the function, assuming SFML found the correct entry point to call, which is why I suggested what I did.

dabbertorres · « **Reply #11 on:** October 21, 2014, 12:23:58 am »

Right... Completely forgot about SDL, sorry, my bad.

miotatsu · « **Reply #12 on:** October 21, 2014, 01:10:24 am »

Quote from: binary1248 on October 20, 2014, 11:28:44 pm

Try changing "glXSwapIntervalSGI" in this line to "glXSwapIntervalMESA" or "glXSwapIntervalEXT" and build SFML and see if it works. Make sure to get rid of all traces of SFML that are currently on your system before doing this. If this "fix" works, it smells like another case of a broken driver.

Will try this later tonight

Quote from: dabbertorres on October 20, 2014, 11:38:33 pm

So, as he is on Intel graphics, he needs to edit /etc/X11/xorg.conf.
Find the Driver "intel" line, and in that section, add
Option "SwapbuffersWait" "false".

With this, the problem is reversed. vsync is off, but SFML is unable to turn it on.
Edit: Not exactly reversed, as the SDL example was unable to turn it on too.

miotatsu · « **Reply #13 on:** October 21, 2014, 11:02:08 pm »

Sorry for the late response, but changing "glXSwapIntervalSGI" to "glXSwapIntervalMESA" does indeed "fix" the problem.

binary1248 · « **Reply #14 on:** October 21, 2014, 11:14:57 pm »

Oh yay... another broken driver

. I guess the fix for this will be simple. Can you check whether the pointer returned (i.e. the value of glXSwapIntervalSGI) is valid or 0 for "glXSwapIntervalSGI"? If it is valid, there is no way for SFML to check programatically if the call actually worked. If it isn't valid, SFML would be able to look through multiple entry points instead of only a single one as is currently the case.

Author Topic: vsync always on? (Read 10097 times)

miotatsu

vsync always on?

binary1248

Re: vsync always on?

eXpl0it3r

Re: vsync always on?

miotatsu

Re: vsync always on?

binary1248

Re: vsync always on?

miotatsu

Re: vsync always on?

dabbertorres

Re: vsync always on?

miotatsu

Re: vsync always on?

binary1248

Re: vsync always on?

dabbertorres

Re: vsync always on?

binary1248

Re: vsync always on?

dabbertorres

Re: vsync always on?

miotatsu

Re: vsync always on?

miotatsu

Re: vsync always on?

binary1248

Re: vsync always on?