For example, Unigine Tropics benchmark gives 20fps, but with vblank_mode=0 it's 54fps. Games that don't turn off vsync by themselves suffer from this as well.
(In reply to comment #0) > For example, Unigine Tropics benchmark gives 20fps, but with vblank_mode=0 > it's 54fps. I can only reproduce this with vblank_mode=2 or =3, though AFAICT the default is 2. > Games that don't turn off vsync by themselves suffer from this as well. Actually, as long as the game can sustain at least 60 fps (or whatever the display refresh rate is) with vblank_mode < 2, it should still get 60 fps with vblank_mode >= 2, and IME that's indeed the case with a lot of games. The issue with Tropics is that it can only sustain just below 60 fps, which becomes 30 fps (half the refresh rate, since it misses every other vertical blank period) with sync-to-vblank, and then there are some scenes where it drops even lower. We will hopefully be able to handle this better with DRI3/Present.
Thanks for the clarification about vblank_mode. With the default vblank settings Tropics always stays in the range of 15-25 fps.
Why don't we disable vsync by default? I think that's what proprietary drivers do.
(In reply to comment #3) > Why don't we disable vsync by default? > I think that's what proprietary drivers do. Because that's relevant only for benchmarks. Normal applications want to present user complete (non-tearing) frames. Note: with DRI2, using fullscreen with vsync off causes X to do copy of every frame (which has clear performance penalty for memory bandwidth bound benchmarks). With DRI3, when Vsync is disabled on client side, the X side copy is done only every Vsync, but currently you would need quad buffering to avoid stalling from X server side synching, which isn't what Mesa does (see bug 79715). (If you're very close, but not quite at 60 or 30 FPS, this non-Vsync induced copy can cause your FPS even to slightly decrease compared to Vsync.)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/521.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.