-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Allow limiting editor 3D viewport fps #8607
Comments
The 3D editor respects the vsync setting in the project settings. How are you measuring FPS? Keep in mind the "View Frame Time" overlay displays "potential FPS" not actual FPS. I.e., it doesn't take Vsync into account. It calculates an FPS based on the CPU and GPU usage. Basically it is "your FPS could be this high if it wasn't limited by Vsync or frame rate limit" |
I am using the View Frame Time overlay, I can't measure fps using the radeon tools (since they don't see the godot editor for some reason) and I don't have MSI afterburner installed or other relevant tools. I did try to change project settings (combinations of vsync on/off, max fps and scaling, since these were modified in the project I had open when I noticed) and none of these seem to make any difference in gpu usage, other than FSR 2.2 having slightly higher gpu usage (and the jitter but that's not immediately relevant here I think). I typically will turn vsync off and framelimit to 61 fps on new projects, this was true for when I was using Godot 3 as well, just as an example of usage in case that gives any hints as to what I should test next. Also, I tried changing the radeon settings (I have all the relevant features disabled, so no chill or frame rate target control) and I didn't notice any difference in gpu usage with vsync forced on, force off or letting the application decide with default being off. There may be subtleties here of course, it's hard to measure this with complete precision without doing very controlled tests but my expectation would be that vsync on vs off, regardless of whether it's obeying the project rules internally or enforced by the driver, should show more of a difference but I see it hover around the same gpu usage (26-33% in the last tests I did just now on 4.2 with an empty project, while focused) regardless of the settings. I also tried 3.5.1 which clearly does respect the vsync setting set in the project settings (but since it is on opengl I'm guessing you're specifically referring to vulkan/forward+ not showing actual fps) as it shows 60fps exactly while on vsync, 143-144 fps without it (regardless of fps limit set in project settings) and drops to 20 fps while unfocused (according to the fps measurement the editor mentions). The gpu usage is accordingly changed: without vsync, empty scene in 3.5.1 uses 50% gpu, with vsync it uses 22%. If somehow it is my own machine that is not acting as it should and these limits would otherwise be respected in 4.0, then I'll check my drivers to see if something is wrong there. |
That's strange. The Nvidia Control panel detects and allows me to limit Godot's framerate just fine, not that I personally would want to, though.
At some point I think @Calinou told me the editor was always vsync'd, but I may be mistaken.
Yup, yup. But it's been argued to be confusing, see godotengine/godot#75512 . |
godotengine/godot#48364 isn't merged yet. |
It sounds like this may just be a duplicate of godotengine/godot#69218 As Mickeon pointed out, we have a PR where we are discussing improving the "view frame time" overlay as it is currently confusing (godotengine/godot#75512). Earlier we discussed various ways to communicate that this value is potential FPS and not actual FPS (subject to Vsync/limiting), but we couldn't settle on something that we were happy with (godotengine/godot#69228) |
While that issue is about the actual fps not being shown and mine is mostly about gpu usage not being limitable, in a way the solution already in the PRs seems to satisfy both (in terms of both the indication and the limiting of gpu usage). I'm not sure how vsync would interact with overall gpu usage etc. but it seems to be gentler in modern implementations than the ancient ones (unrelated to godot) that made me want to turn it off everywhere (because it would just max out the gpu anyway) and use frame limiting instead. Though I would still prefer an actual frame limit as we have it for projects, I would be happy with just being able to enforce vsync in the editor. Either way, if the PRs are merged, things wouldn't be worse, just the same and if users like me have issues with the options being just vsync or no vsync, then I guess those issues can be dealt with more specifically and a frame limit can be discussed again. If there is a nightly with that PR included, I would like to test it. I remember Calinou used to have nightlies but they're not there anymore and preview builds only has a Godot 3 version. I could just build it myself but since I haven't done it before it might take a while xD In the meantime, I'll update my drivers and see if the newer version has any control over the godot editor, just in case. edit - driver update didn't change any of the above |
You can already enforce a custom FPS cap in both 3.x and 4.x by changing Low Processor Mode Sleep Usec in the Editor Settings (higher values result in a lower FPS cap – try |
Ah yes this does seem to work, I see reduced gpu usage as expected and it's still responsive at the ~30 fps cap you suggested, thankyou. It wasn't clear to me this option would have this effect so I probably overlooked it even though I was aware of it. I am at fault for not testing without the frame time overlay as well, sorry. The above option does work even with it on. I checked again and it seems it was a combination of factors that cause the high gpu usage case. Part of this was my default turning off of vsync in project settings, which I didn't know had an effect on the editor (being used to how 3.5 worked), as well as having it off in the gpu driver settings because I in general I just use framelimiting. Using the frame time overlay was just forcing updates and my experience with 3.5 made me think it wasn't at fault. When I was originally using 3.5, I was on a different machine and I had radeon chill on by default, which I didn't realise could influence the editor (because it was showing 144 fps) so it may have made me think it doesn't update unless necessary, whereas now I have it off because framelimiting is available for the case I needed it for. Radeon chill does work but it has a delay until it turns on and I may have not always been waiting for it - trying to toggle it with the hotkey does produce the expected effect. The framelimit from the driver seems to have no effect other than making the gpu timing in-editor look like it's vsynced (at 8ms/~125fps for some reason) but without changing the high gpu usage (which I don't understand). Turning the frame time overlay off does also stop the FSR 2.2 jitter (at scaling 1.0 and below), so I underestimated how much of an effect that had and I don't know the differences between FSR 1.0 and 2.2 to guess as to the cause. In all, I think the PRs that change the frame time overlay and add the separate option for vsync in the editor (as well as the tip about low processor mode) solve the problem sufficiently. Whether this was a user error or presents a usability issue is not for me to decide at this point, so as far as I can tell, this proposal has little purpose other than reinforcing already solved problems so I'm closing it. I didn't manage to build godot from the vsync option PR (I get scons errors I don't know how to fix) but my guess is that since project vsync settings apply to the editor, the PR shouldn't change any of the above. Sorry if I wasted your time. edit - forgot to mention I replicated the 100% gpu usage case: with chill off, fps limit from the driver off, vsync off "unless specificed by application" on the driver, default 6900 usec on low processor mode, vsync off from the project settings and the fps overlay on, gpu does reach 100% usage on the empty scene, and overlay says 144fps while focused with gpu time at 7ms. Unfocused, gpu usage drops to 12%. At half resolution fps is 440ish, gpu time 2.3ms and gpu usage at 60% while focused. All with FSR 2.2. So this was what I encountered. |
Describe the project you are working on
This isn't specific to any project, it is related to the usability of the editor itself and applies to any project that uses 3D.
Describe the problem or limitation you are having in your project
The editor's 3D viewport does not limit its framerate and there is no way to do so from within the editor (or the command line). Attempting to use the Radeon control panel to limit framerate also doesn't work: the control panel doesn't recognise the godot editor and trying to use any and all global graphics settings such as radeon chill, fps limit or forcing vsync everywhere doesn't make any difference either, even with an editor restart.
Adjusting project settings to set a maximum fps value does work in the project but not in the editor. Using command line options such as
--max-fps
or--frame-delay
do not affect the editor.Without an fps limit, the editor just uses 100% (or nearly 100% edit: this seems to occur in some cases, I may have found a bug, investigating it. Mostly gpu usage in an empty project is around 30% on an empty scene) of the gpu to render, with the framerate reaching 800-1500 fps for no reason. This limits multitasking with other 3D applications (and may cause lag in others that require occasional rendering or gpu usage for processing) and causes the gpu to run at maximum just by selecting the 3D tab in the editor (edit: see above, may be a bug). It also doesn't seem to limit its framerate when not in focus, which I think is the intended behavior so that may be a bug (edit: it does reduce gpu usage when not in focus, may have something to do with my project, though the scene is empty).
This wasn't true for prior versions. The last version of Godot 3 I was using (3.5.1) would have a hard limit of 144 fps, which was acceptable even though both my monitors are 60Hz. It did prevent excessive gpu usage and by using the half-resolution option I was happy with the gpu usage. The earliest I noticed this new behavior was with Godot 4.1.1.
For reference, these are my relevant specs:
Addendum:
* edit: It seems something is happening with FSR 2.2 (in regards to the visual jitter), which I can avoid for the time being. Either way, the proposal stands, as it pertains to unnecessary resource usage, it occurs even with Bilinear scaling (it goes up to 50%+ when focused, on the same empty scene) and FSR 1.0
Describe the feature / enhancement and how it helps to overcome the problem or limitation
An fps limit for the editor (specifically 3D viewports since this doesn't seem to be an issue anywhere else - the editor updates when needed and no more often, though I have not tested animations running in a 2D viewport or the like), similar to what we can configure for projects. For the problem to be solved, this fps limit would have to apply to all cases where there can be excessive gpu usage in the editor, though for now I'm only aware of the 3D viewport acting in this way.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
An option under editor settings, even if it's under advanced settings, for a maximum framerate for the 3D viewport (and the rest if it impacts them, though it doesn't seem to at present) would be sufficient, even if it's not on by default.
Alternatively, a command line option would work, though perhaps some users would prefer to be able to change this limit without having to restart the editor.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It is a core part of the editor's rendering and I'm not aware if this is functionality exposed to editor extensions or if it would require recompilation. So for the vast majority of uses, this isn't something that can be worked around, since external fps limiting may work for some but not all, such as myself.
Is there a reason why this should be core and not an add-on in the asset library?
It is an essential usability feature for the editor since it impacts multitasking, power usage and gpu resource allocation (not to mention the unnecessary fan noise). I feel this should be available by default and an implementation outside the core may be prone to bugs, limitations and breaking.
The text was updated successfully, but these errors were encountered: