Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

[rbp] Enable Vsync as a default #2388

Merged
merged 1 commit into from

5 participants

@popcornmix
Collaborator

I'll start this PR with the simplest fix, but it's more of an RFC.

Raspberry Pi currently defaults vsync to "let driver decide". This defaults to disabled.

For a low specced device, this is a bad default option.
Rendering more frames than you can display is pointless. Even f you do choose to use a 24/25/30 Hz mode, then the GUI still tries to update at 60+ fps and the cpu hits 100%.

I think a better fix would be to keep the default vsync as "let driver decide" (for Pi, and probably all platforms). And change the driver's default to enabled.

Would anyone object if this was the case for all platforms?
Is there any reason to run fps above vsync rate apart from benchmarking (which is still available with "always on"

@arnova
Collaborator

With some hardware VSYNC causes eg. issues like high-cpu usage and such, so there is no "perfect" default :/

@popcornmix
Collaborator

Could we make a list of what platform's don't want VSYNC?
It seems hard to imagine how limiting framerate to VSYNC can ever use more cpu.

I would like to claim that all GLES platforms do want VSYNC enabled. Any counter-examples?
If I said all GLES platforms want VSYNC enabled, any counter-examples?

@akva2

uhm, how can it be hard to imaging vsync can every use more cpu?

the cpu is waiting for the retrace. on good drivers you get a callback from the gpu when the vsync occurs (or well, rather when the buffer switch occurs). on bad drivers you don't and have to poll. either you have it sleep, and miss a retrace (bad idea), or you have to spin. last mode eats cpu like babies.

@arnova
Collaborator

Broken drivers. Seen it happen with Intel for example (in combination with older hardware)..

@popcornmix
Collaborator

I would consider a graphics driver that busy waits for a vsync to be fundamentally broken.

Even so, if 1% of people are using such a driver, and they end up with high CPU after the change, which is fixed by changing the vsync option, and 99% of people get a an improved, lower CPU xbmc after the change, then it still sounds like a win.

I'm still going to claim that no GLES system suffers from this brokenness, and would benefit from enabling VSYNC. Any counter-examples?

@davilla

is ok with me as it only touches rpi

@huceke huceke merged commit 4d7c659 into xbmc:master
@popcornmix popcornmix referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
@popcornmix popcornmix [rbp] Enable Vsync as a default
This was done in #2388, but got lost in the setting refactor and is currently disabled
a63385f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 7, 2013
  1. @popcornmix
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 1 deletion.
  1. +1 −1  xbmc/settings/Settings.h
View
2  xbmc/settings/Settings.h
@@ -36,7 +36,7 @@
#ifdef MID
#define DEFAULT_VSYNC VSYNC_DISABLED
#else // MID
-#if defined(TARGET_DARWIN) || defined(_WIN32)
+#if defined(TARGET_DARWIN) || defined(_WIN32) || defined(TARGET_RASPBERRY_PI)
#define DEFAULT_VSYNC VSYNC_ALWAYS
#else
#define DEFAULT_VSYNC VSYNC_DRIVER
Something went wrong with that request. Please try again.