Godot 4.0 is very slow to start on macOS compared to 3.x #62322
Comments
|
Can you reproduce this with previous 4.0 alphas? Note that in general, startup speeds are in 4.0 expected to be slower than 3.x, but they shouldn't be more than twice as slow. However, the first startup will always take significantly more time due to the shader cache having to be warmed. On slower hardware, this can indeed require 20-30 seconds on the first startup, but subsequent starts of the project manager, editor and project (on a per-project basis) should be faster until you update your graphics driver. |
Calinou
changed the title
|
I really want to see some improvement with start-up time. Keep in mind the first start-up is the first impression users have with Godot. Going from ~5 seconds to 30 seconds lessens my perception of Godot as a light-weight engine. |
|
@Calinou Thanks for the comment! I think that when it comes to this particular setup (MacBook Pro with an Intel Iris Pro 5200 integrated GPU) the performance issue is more serious than in other similar cases. I think I haven't highlighted it clearly - that 30 seconds slowdown during the Godot editor start as well as the startup of an app/project (including an empty scene) happens every single time 🙂 Namely, when I run the app with a play button for the first time, it takes the app about 30 seconds to start. But then, when it's closed and started again, it still takes 30 seconds to start. Even after the editor restart or the OS restart the issue remains. My guess is that some caches (like the shader cache you've mentioned) are not used at all, so they're never warmed up. Also, I think that the error log I've posted in the first comment could give us some clue. Mainly because I've tested Godot 4.0 alpha 10 on the other laptop as well, a newer MacBook Pro (Touch Bar, 16-inch, Late 2019) and there's no issue with the permanent slow startup. I mean, the first run of the editor is about 30 seconds as well, but then it pops up quickly, just in a few seconds. Also the app/project startup is not an issue. The first run was slow but the consecutive restarts are almost instantaneous, like they were in Godot 3.4. For the record, that newer MacBook has the following spec:
MacBook Pro (Retina Mid 2015) may seem pretty old when compared to it, but it was discontinued not that long ago. Apple was selling those Retina laptops until 2018. Oh, and by the way... I've also tested Godot 4.0 alpha 1 and Godot 4.0 alpha 9 with my older MacBook Pro (Retina) as well. Unfortunately, there is no difference between those alphas and the current one, when it becomes to that slow startup issues. I've cleared all Godot-related files (including system caches and other files mentioned in the Homebrew formula's "zap trash") and restarted the OS (macOS loads some caches during every system start) before every new alpha version installation, so I guess all these benchmarks are valid. I don't have experience in Vulkan API (I've done some quick tutorial once) and I haven't written any serious C++ for ages now, but if there's any way I could help with this issue - please let me know. I will try my best. Thanks! |
|
I think we should profile the startup and see if there's any easy gains or fixes to be made there. Gut feeling says the new renderer alone shouldn't add that much startup time, especially not under Vulkan. |
|
I ran benchmarks of all versions since Godot 3.0.1 up to 4.0.alpha10: SpecificationsOS: Fedora 36 Using official Godot Linux x86_64 release binaries downloaded from TuxFamily. Benchmark source and data files (CSV, JSON, Markdown) are available at: https://github.com/Calinou/godot-startup-times ResultsCold project manager start + exit
Warm project manager start + exit
Cold editor start + exit
Warm editor start + exit
ConclusionThe main takeaway is that 4.0.alpha10 is much slower to startup and shutdown compared to 4.0.alpha9, especially in cold runs. This suggests that the shader cache has more work to do since more shader variants have to be compiled, presumably due to TAA. cc @JFonS 4.0.alpha6 also has a noticeable regression in startup/shutdown speed compared to 4.0.alpha5 (both cold and warm), but mainly in the project manager. |
|
I'm on Windows and I get close to 10 seconds of boot time significantly slower than 3.x. Also the entire experience is very sluggish until I turn off multi window mode then is fine. |
|
For me this is around 30 seconds usually on 4.0. Before on 3.3 it launched under a couple of seconds. |
|
My issue specifically has to do with Iris Xe driver multi window & Godot 4 compatibility on Windows . Should I make a new post? |
|
I have this problem as well and looked into it a bit. I don't have a solution but my findings so far is that one call to vkCreateGraphicsPipelines (for the shader ClusterRenderShaderRD:0) takes 30s. What happens is that the separate MTLCompilerService process crashes, and the caller times out & continues after 10 seconds. (It does 3 retries however, hence a 30s total delay). So it doesn't seem to be a shader cache performance issue per se like @Calinou investigated, but a bug, possibly in the MoltenVK/Metal backend. As for why it's crashing is a bit more unclear. The callstack of the crashed thread in MTLCompilerService is: It seems to me like it encounters an error, but fails to properly report it and crashes instead. While compiling it also emits I don't know if there are any more Vulkan/Metal logs to check, but let me know if there's some place I should have a peek. |
|
There's a fair chance this issue is a MoltenVK bug, which we unfortunately can't fix on our end. |
Calinou
changed the title
|
Developers of the Dolphin emulator experienced some MoltenVK performance regression recently, maybe this can help |
Yes, unfortunately. It's maybe possible something in the shader triggers the error and can be avoided by adjusting it somehow, but the error reports I currently have available aren't that much to work with. |
|
It does seem like the MTLCompilerService reports (or tries to report) an error. Considering the "reportUnsupportedFunctionReferenceError", my wild guess without knowing Vulkan would be that the shader uses a function that isn't supported by the MoltenVK backend or something? If I could see the actual error output I could maybe see exactly what, or at least more error information. The error report seems to lead to an abort of the process though and I don't know if it actually writes the error output anywhere. |
|
MacBook Pro (Retina, 15-inch, Mid 2014) has the same question. Only open the editor without arguments causes the question. If start it with a project, it works fine: I also tested it on MacBook Pro (16-inch, Mid 2019) with same OS version and same Vulkan API version, it worked properly. |
|
@kdada This is an unrelated issue. Also, your project is using the Forward Mobile backend, which is more compatible with lower-end desktop GPUs (including old Macs and MoltenVK in general). On the other hand, the project manager always uses the Forward Plus backend, even on GPUs that don't support it well. The project manager should probably always use the Forward Mobile backend (or Compatibility on GPUs that don't support Vulkan), as there is no point in using the Forward Plus backend for it to my knowledge. |
|
Ok so I did a bit of a deep dive on this one, and basically yes the Metal compiler crashes and However, with a bit of testing I figured out that what actually triggers this error is the usage of In my case it's taking the non- I'm not sure making a pull request of that makes sense because those conditionals are obviously there for a reason, and I'm not well versed enough in the shaders to know what the best alternative is. (As I understand it they're there to avoid doing unnecessary calculations when the shader is run in a helper mode that doesn't actually output anything, so removing it likely doesn't cause any errors but may have performance effects. If I read the docs correctly atomicOr doesn't actually do anything when in a helper invocation though so possibly it's just basically a free NOP anyway, but someone who actually knows what they're talking about should chime in.) As an extra reference, this specific code is actually discussed in a separate but related discussion about subgroups + helper invocations in a Khronos GLSL issue, mentioning @reduz : KhronosGroup/GLSL#35 I'd be happy to test alternative fixes on this computer where it normally fails, just let me know. |
|
@SonnyBonds I think removing the It would be helpful if you could test a version with the |
Yeah, exactly. It doesn't really specify if they're also "free" though, but I'll try to see if I can do some performance tests. Are there any useful benchmarking scenes readily available somewhere? I could probably also wrap the conditional so it's only skipped when using MoltenVK. I'll have a look and make a PR when I have some results. |
You can take a look at the 4.0-dev branch of the demo projects, some have been updated for 4.0. I think the antialising demo should work if you add a bunch of lights to it https://github.com/godotengine/godot-demo-projects/tree/4.0-dev. For stuff like this I usually just use sponza from here https://casual-effects.com/data/ and then add some smaller meshes and lights manually
That would be fine as well! |
You can use https://github.com/Calinou/godot-reflection for this purpose 🙂 I've tested it and can confirm it works on 4.0.beta3. |
|
I think there needs to be a new issue since a lot of people seem to be reporting on other issues some graphic driver related slowdowns. I think the issue is from Vulkan implementation in Godot that is causing slowdowns probably because there is something that's not being properly initialized and the application waits for it? |
This is already being tracked in #43351. In general, Vulkan is expected to be slower to initialize compared to OpenGL – it's a more complex rendering backend. |
|
Hello, I want to apologize if I wrote this in the wrong place, I have 2 videos, on the first video I shot errors when launching Godot 4 beta 4, and the launch time itself; and on the second one, I recorded the interface lags that appeared in the new beta version Screen.Recording.2022-11-04.at.22.50.55.movScreen.Recording.2022-11-04.at.22.46.07.mp4 |
|
@Ghashy See #68269. There appears to be a performance regression between 4.0.beta3 and 4.0.beta4. If you can compile the engine from source, you could look into bisecting the regression to greatly speed up troubleshooting. |
|
Not sure if it helps but: M1 Mac Mini here (Monterey v. 12.6.1), was unable to reproduce on a new Forward+ project, even on cold start. Mine only take a few seconds to load at most (both mono and without), doesn't matter which beta (tested 1-4) nor 3.5.1 nor 3.5 (using a GLES3.0 renderer) All of them were sub 5 seconds. Not sure if it'll help with debugging at all or not. My molten-vk install info in case that helps:
Graphics/Displays:
Apple M1:
Chipset Model: Apple M1
Type: GPU
Bus: Built-In
Total Number of Cores: 8
Vendor: Apple (0x106b)
Metal Family: Supported, Metal GPUFamily Apple 7
Displays:
LG HDR 4K:
Resolution: 3840 x 2160 (2160p/4K UHD 1 - Ultra High Definition)
UI Looks like: 3840 x 2160 @ 60.00Hz
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No |
Godot version
4.0.alpha10.official
System information
macOS 12.4 (Monterey), Vulkan, Intel Iris Pro 5200
Issue description
Latest release of Godot 4.0 (alpha 10) seems to be super slow on macOS 12.4 (Monterey), at least when tested on my MacBook Pro setup (meanwhile, Godot 3.4.4 works without any noticeable performance issues). Here are some benchmarks:
On the other hand, editor itself is generally responsive when interacting with its UI (creating new nodes etc.).
Among important details, here are some errors that are raised during the 2D application start (empty scene):
Also, here's the editor output after Godot start, for the record:
It seems that Vulkan support is not an issue on my MacBook Pro. I've just installed Vulkan SDK 1.3.216.0 for macOS from LunarG website and their
vkcube.appdemo works without any issues (thanks to MoltenVK underneath, of course).I can provide any additional information or testing if that would help.
System details
GPU details (from
system_profiler)And by the way, thank you all for Godot! 🎉 It's absolutely amazing that a game engine like this is available out there.
Steps to reproduce
No extra steps are needed to reproduce the issue. It seems that any MacBook with a similar spec would be prone to this problem.
Minimal reproduction project
No response
The text was updated successfully, but these errors were encountered: