Godot: Freezing on GLES3

Created on 14 Dec 2018  路  12Comments  路  Source: godotengine/godot

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:

  1. Editor or game was started (particularly if there's numerous 3D assets on the main scene)
  2. Any setting on a SpatialMaterial or Environment is modified
  3. Going from windowed to fullscreen and back again
  4. Adding a camera
  5. Adding an Environment to a WorldEnvironment node
  6. Modifying the environment
  7. Adding a material
  8. Modifying the material

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:

  1. Create a new project
  2. Add a MeshInstance
  3. Add any Mesh resource to the MeshInstance; the editor may lock up for an extended period
  4. Add a Material to the Mesh; it may lock up again
archived

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].

  1. https://gitlab.freedesktop.org/mesa/mesa/-/commit/95f555a93a8891ebba2a291eecd984eb2364d636
  2. https://gitlab.freedesktop.org/mesa/mesa/-/issues/2996

All 12 comments

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:

  • Mesa 20.1.0_rc3 (Still need to test previous versions.)
  • xf86-video-amdgpu 19.1.0
  • DRM 3.36.0
  • LLVM 10.0.0
  • GCC 10.1.0 (Also tested building mesa and xf86-video-amdgpu with 9.3.0.)
  • Godot Engine v3.2.1.stable.official

@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. :]

  • AMD Ryzen 7 1700
  • PowerColor AMD Radeon RX 5700 XT
  • ASUS PRIME X370-A
  • 40 GiBs of RAM

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].

  1. https://gitlab.freedesktop.org/mesa/mesa/-/commit/95f555a93a8891ebba2a291eecd984eb2364d636
  2. https://gitlab.freedesktop.org/mesa/mesa/-/issues/2996
Was this page helpful?
0 / 5 - 0 ratings