Godot version:
01fa0673a4165d3245d6b22e99b0e4ea99d19c5b
OS/device including version:
Arch Linux | AMD CAPE VERDE (DRM 2.50.0, 4.19.8-arch1-1-ARCH, LLVM 7.0.0)
Issue description:
Since today, the Godot editor and tested games are sometimes freezing up between 15 seconds to several minutes under the following conditions:
These conditions don't always cause freezes. While frozen, Godot will eat up between 10-30% of CPU power. On GLES2, none of these problems appear to exist.
Steps to reproduce:
Since today
Do you remember what previous you had that worked well? Do you reproduce the bug in 3.1 alpha 3?
@akien-mga I tried it out with other versions of Godot, and it seems to happen there as well, so now I'm thinking it's really something going wrong with my system; false alarm!
I'm having the exact same issue, and have been every time I've used Mesa 18.3 on Arch. Let me know if you find out if it was your system after all. I am running into this issue on Godot 3.0.6 and 3.1 alpha 3.
@turtlewit This is indeed a problem with Arch, I assume because it's using a newer driver. I'm back on Manjaro for now, which seems to be lagging behind Arch as Godot is OK here, but I fear it will eventually update and I'll be unable to use Arch-based at all for Godot development.
In any case, I assume this is a problem unrelated to Godot. @akien-mga
@turtlewit Speak of the devil, just updated and now Manjaro as affected. So as far as I can tell, all Arch-based distros now have major performance problems in 3D, assuming they aren't using Nvidia (can't find anyone who has been having this issue using that setup.)
I'll reopen for now.
That's not a Godot bug, you should file a bug report at Arch against the Mesa package.
Both Fedora and Debian were hit by a GCC bug when building Mesa 18.2.3 a month ago against latest GCC, see https://github.com/godotengine/godot/issues/23423#issuecomment-435877238
I'm surprised Fedora and Debian would catch such "cutting edge" bugs before Arch, but that might be the case.
I wonder if this has resurfaced? Before I go reporting bugs elsewhere, I figured I'd ask if people watching this are seeing what I see, and see if I can get a confirmation of this being expected or not.
For example, first launch of 'Engine/demos/viewport/3d_in_2d' with a clean '$HOME/.cache/mesa_shader_cache/' takes more than 40 seconds. There are situations in a game I'm testing where it can take at least as long as 1 minute 30 seconds for things to get going again. For some things a smaller freeze persists even after the initial one (this smaller freeze happens only once when using NVIDIA, and the other, initial freezes are much shorter there).
Software versions used on this Gentoo Linux install include:
@Chiitoo Sounds like shaders compiling. Especially since clearing the shader cache affects it.
1.5 minutes is an unusually long time for shader compilation, could be some combination of driver issues/old hardware.
Posting your hardware info would help.
You could try on GLES2, if it is a shader compilation issue then it should be improved in GLES2
Duh, somehow forgot the hardware bits. :]
Indeed, switching to GLES2 makes things rather instantaneous.
Thanks!
@Chiitoo so it is shaders compiling. Unfortunately, not much you can do about it then. That was one of the big reasons we added the GLES2 backend, and a reason we are switching to Vulkan.
This thread discusses some possible workarounds https://github.com/godotengine/godot/issues/13954
Ah, cool. I had not bumped into that one yet.
Thanks again!
Figured I'd mention this here, too, in case someone bumps into it.
I've bisected the worst of it being regression in Mesa, since commit 95f555a9 [1}. Without this change, the '3d_in_2d' test drops from around 30 to 40 seconds to less than 2 seconds.
Filed an issue upstream already [2].
Most helpful comment
Figured I'd mention this here, too, in case someone bumps into it.
I've bisected the worst of it being regression in Mesa, since commit 95f555a9 [1}. Without this change, the '3d_in_2d' test drops from around 30 to 40 seconds to less than 2 seconds.
Filed an issue upstream already [2].