Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure and reimplement v-sync options #48622

Merged

Conversation

Geometror
Copy link
Member

@Geometror Geometror commented May 10, 2021

This PR is a complete reorginization of the v-sync related code for DisplayServers with the changes discussed here and on IRC. So it's no longer a reimplementation of PR #36862, altough @giarve's work was very helpful.

@Geometror Geometror requested review from a team as code owners May 10, 2021 19:17
@Calinou Calinou added this to the 4.0 milestone May 10, 2021
@Calinou
Copy link
Member

Calinou commented May 10, 2021

I can confirm it works on Linux + NVIDIA: image

Testing project: test_vsync_disable.zip

@Geometror Geometror force-pushed the reimplement-disableable-vsync branch 2 times, most recently from c5c3224 to e896526 Compare May 10, 2021 20:11
@Geometror Geometror force-pushed the reimplement-disableable-vsync branch 2 times, most recently from c229cac to 4aa4a33 Compare May 23, 2021 15:37
@Geometror
Copy link
Member Author

Rebased and partly restructured,
vsync setting is now read in Main::setup2 + removed dead code in OS

What is the plan for vsync_via_compositor in 4.0? The code regarding vsync_via_compositor is currently dead in master.

@Calinou
Copy link
Member

Calinou commented May 23, 2021

What is the plan for vsync_via_compositor in 4.0? The code regarding vsync_via_compositor is currently dead in master.

I think it would be better to remove it, as it doesn't work correctly for everyone. It causes the framerate to halve unexpectedly on some setups. Physics step interpolation, syncing frame delta after draw, fixing negative delta values and frame delta smoothing will likely be enough to provide a good experience regardless of potential compositor issues.

@Geometror Geometror force-pushed the reimplement-disableable-vsync branch from 4aa4a33 to 079f65f Compare May 24, 2021 01:34
@Geometror Geometror requested review from a team as code owners May 24, 2021 01:34
@Geometror Geometror changed the title Reimplement disableable V-Sync Reimplement disableable V-Sync and restructure V-Sync code May 24, 2021
@Geometror Geometror force-pushed the reimplement-disableable-vsync branch from 079f65f to e6ca83b Compare May 24, 2021 01:43
@Geometror
Copy link
Member Author

Ok, I removed the V-Sync via Compositor option entirely, now its ready for review :)

@clayjohn
Copy link
Member

Looks interesting, but is this not just a reimplementation of #36862? See this comment #36862 (comment) for reduz' response to that PR.

I echo reduz' concern and I am not certain that just grabbing the first available V-sync format is the proper way to expose vsync to users.

Can you elaborate why this is the best approach for exposing v-sync? Please pardon my ignorance if it is something obvious.

@Geometror
Copy link
Member Author

Geometror commented May 25, 2021

It is a reimplementation of #36862, but moved to DisplayServer as requested by reduz. In addition I removed the broken vsync via compositor option.
Managing v-sync that way(choosing the first available v-sync present mode) could keep it simple and uniform between the Vulkan renderer and the upcoming GLES renderer. As giarve mentioned VK_PRESENT_MODE_FIFO_KHR in #36862 is the only mode required to be supported, so it makes sense to prefer it over the others as the driver may support it the best. However, I think providing the user with an option to choose the preferred "v-sync enabled" present mode would be a good idea. (mainly between MAILBOX[could reduce input lag] and FIFO[guaranteed supported], FIFO_RELAXED isn't that useful imo)
Do you think that would be a better way to expose v-sync to users?

@clayjohn
Copy link
Member

I'm not certain what the best way to expose the vsync settings to the user is.

I don't think falling back to VK_PRESENT_MODE_FIFO_RELAXED_KHR makes sense when a user disables v-sync but does not support VK_PRESENT_MODE_IMMEDIATE_KHR.

I think one option may be to have a toggle (between on and off, if VK_PRESENT_MODE_IMMEDIATE_KHR is not available then try the selected v-sync mode) and a dropdown menu (for v-sync mode, defaulting to VK_PRESENT_MODE_FIFO_KHR and falling back to VK_PRESENT_MODE_FIFO_KHR if selected mode is unavailable).

That being said, I'm not sure that it makes sense to do it like that, for android it looks like VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR may be more suitable when v-sync is disabled (because VK_PRESENT_MODE_IMMEDIATE_KHR is never available)

@Geometror
Copy link
Member Author

Ok, I will look into that. By digging through the codebase I found out that it is more work than I initially thought, so I should change this PR to a draft as there are still some things to decide, restructure and implement. Maybe I should ask reduz if he has concrete plans for v-sync atm.

@Geometror Geometror marked this pull request as draft May 25, 2021 18:14
@clayjohn
Copy link
Member

@Geometror that is a good idea. Reduz typically has some ideas for this kind of stuff, and it is important to work on soon as we are approaching alpha.

@Geometror Geometror force-pushed the reimplement-disableable-vsync branch 4 times, most recently from 5f41303 to bea4958 Compare May 30, 2021 14:58
@Geometror Geometror reopened this Jun 2, 2021
Copy link
Member

@akien-mga akien-mga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good!

doc/classes/DisplayServer.xml Outdated Show resolved Hide resolved
doc/classes/DisplayServer.xml Outdated Show resolved Hide resolved
doc/classes/ProjectSettings.xml Show resolved Hide resolved
drivers/vulkan/vulkan_context.cpp Outdated Show resolved Hide resolved
drivers/vulkan/vulkan_context.cpp Show resolved Hide resolved
@akien-mga akien-mga requested review from Calinou and reduz June 7, 2021 07:23
@Geometror Geometror force-pushed the reimplement-disableable-vsync branch 4 times, most recently from e5f2cba to c635d3d Compare June 10, 2021 01:36
@Geometror Geometror force-pushed the reimplement-disableable-vsync branch 2 times, most recently from ea9b5f5 to 3c8bae7 Compare June 19, 2021 15:45
@Geometror
Copy link
Member Author

Rebased.
@Calinou Do you think I should include the editor VSync option from your 4.0 PR (#48364) as part of the whole VSync options reimplementation? Because when/if this is merged, that PR must be redone anyway, so I could save you some work.

@clayjohn
Copy link
Member

@Geometror I think it is best for each PR to do one thing. My preference is to merge this PR first and then look at Calinou's PR after.

-Add a v-sync mode setting which allows to choose between DISABLED, ON, ADAPTIVE and MAILBOX
-Removed the V-Sync via Compositor option
@Geometror Geometror force-pushed the reimplement-disableable-vsync branch from 3c8bae7 to 043ae91 Compare July 6, 2021 14:39
Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally with this PR rebased against the latest master branch. All options seem to work as expected on Linux + NVIDIA.

Edit: Tested on a Windows 10 + Intel IGP setup, it works as expected there too.

@Calinou
Copy link
Member

Calinou commented Jul 9, 2021

Thanks!

@Calinou Calinou merged commit a2d5f19 into godotengine:master Jul 9, 2021
@@ -1114,6 +1114,7 @@ ProjectSettings::ProjectSettings() {

// Keep the enum values in sync with the `DisplayServer::ScreenOrientation` enum.
custom_prop_info["display/window/handheld/orientation"] = PropertyInfo(Variant::INT, "display/window/handheld/orientation", PROPERTY_HINT_ENUM, "Landscape,Portrait,Reverse Landscape,Reverse Portrait,Sensor Landscape,Sensor Portrait,Sensor");
custom_prop_info["display/window/vsync/vsync_mode"] = PropertyInfo(Variant::STRING, "display/window/vsync/vsync_mode", PROPERTY_HINT_ENUM, "Disabled,Enabled,Adaptive,Mailbox");
Copy link
Member

@Calinou Calinou Jul 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed this is a string enum rather than an integer enum. I think using an integer enum would be better as it's more Godot-y overall. (We're trying to move away from string usage when possible in 4.0 onwards.)

Also, in places where we use a string enum (such as the stretch mode project setting), we use snake_case strings instead of PascalCase.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume I just copied how it was done for the screen orientation (which was before you changed it to an integer enum). But you are right, an integer enum is cleaner as it wouldn't need that ugly if-elseif construct in main.cpp. I will open a PR soon to change that.

@Geometror Geometror deleted the reimplement-disableable-vsync branch July 11, 2021 12:25
Comment on lines +365 to +366
virtual void window_set_vsync_mode(DisplayServer::VSyncMode p_vsync_mode, WindowID p_window = MAIN_WINDOW_ID) override;
virtual DisplayServer::VSyncMode window_get_vsync_mode(WindowID p_vsync_mode) const override;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class didn't have override before this, so now Clang complain about the others that are missing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the use of override desired? If so, I could add it where it should be (only display_server_iphone and display_server_osx use it currently), otherwise I could open a PR to remove the keyword from all display_server classes except osx and iphone.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the use of override desired?

Yes, it is. I'm not sure why it wasn't used in those classes before.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened a PR for this: #50513

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for adaptive V-Sync Vulkan: disabling V-Sync not reimplemented yet
8 participants