Creating or loading GPUParticles nodes crashes engine on macOS with Compatibility GLES3 renderer (Apple Silicon)

[elpozewaunig]

Godot version

4.0 beta 16

System information

macOS 13.1, GLES3, Apple M1 Pro GPU

Issue description

When creating a new GPUParticles2D or a GPUParticles3D node while having the editor set to the Compatibility (GLES3) renderer on a macOS device with an M1 architecture, it crashes reliably after a brief delay. This also happens when exporting the project and running it, as well as opening an existing project after switching from the Vulkan renderer to the GLES3 renderer. However, it only occurs when emitting is set to true, a non-emitting GPUParticles node does not cause a crash.

This only happens on macOS, it works just fine on Windows.

Steps to reproduce

1. Create a new project
2. Switch to Compatibility renderer
3. Create a new 2D or 3D scene
4. Create a new GPUParticles2D or GPUParticles3D node
5. The editor crashes, since the node is automatically created with emitting set to true

Alternatively:

1. Open provided minimal reproduction project
2. Change renderer to Compatibility and restart the editor

Minimal reproduction project

Minimal reproduction project (zip)

[yedpodtrzitko]

relevant traceback (copy-pasted from #77681 )

handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.1.dev.custom_build (d9cf3695033a71902010239a27b7a264db7840cc)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x00000001979daa24 _sigtramp + 56
[2] 2   libGLProgrammability.dylib          0x00000001fc63e27c glpLLVMCGSwitchStatement + 176
[3] 3   libGLProgrammability.dylib          0x00000001fc634ad8 glpLLVMCGNode + 588
[4] 4   libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[5] 5   libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[6] 6   libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[7] 7   libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[8] 8   libGLProgrammability.dylib          0x00000001fc650a9c glpLLVMCGIfStatementShortCircuit + 208
[9] 9   libGLProgrammability.dylib          0x00000001fc634ab8 glpLLVMCGNode + 556
[10] 10  libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[11] 11  libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[12] 12  libGLProgrammability.dylib          0x00000001fc63da68 glpLLVMCGFunctionDefinition + 2664
[13] 13  libGLProgrammability.dylib          0x00000001fc633744 glpLLVMCGTopLevel + 1480
[14] 14  libGLProgrammability.dylib          0x00000001fc65b20c glpLinkProgram + 10004
[15] 15  libGLProgrammability.dylib          0x00000001fc675140 ShLink + 208
[16] 16  GLEngine                            0x00000001fc829ac8 gleLinkProgram + 1228
[17] 17  GLEngine                            0x00000001fc797bcc glLinkProgramARB_Exec + 256
[18] ShaderGLES3::_compile_specialization(ShaderGLES3::Version::Specialization&, unsigned int, ShaderGLES3::Version*, unsigned long long) (in godot.macos.editor.dev.arm64) (shader_gles3.cpp:0)
[19] ShaderGLES3::_initialize_version(ShaderGLES3::Version*) (in godot.macos.editor.dev.arm64) (shader_gles3.cpp:678)
[20] ShaderGLES3::_version_bind_shader(RID, int, unsigned long long) (in godot.macos.editor.dev.arm64) (shader_gles3.h:204)
[21] ParticlesCopyShaderGLES3::version_bind_shader(RID, ParticlesCopyShaderGLES3::ShaderVariant, unsigned long long) (in godot.macos.editor.dev.arm64) (particles_copy.glsl.gen.h:29)
[22] GLES3::ParticlesStorage::_particles_update_instance_buffer(GLES3::ParticlesStorage::Particles*, Vector3 const&, Vector3 const&) (in godot.macos.editor.dev.arm64) (particles_storage.cpp:892)
[23] GLES3::ParticlesStorage::update_particles() (in godot.macos.editor.dev.arm64) (particles_storage.cpp:1102)
[24] RenderingServerDefault::_draw(bool, double) (in godot.macos.editor.dev.arm64) (rendering_server_default.cpp:87)
[25] RenderingServerDefault::draw(bool, double) (in godot.macos.editor.dev.arm64) (rendering_server_default.cpp:397)
[26] Main::iteration() (in godot.macos.editor.dev.arm64) (main.cpp:3405)
[27] OS_MacOS::run() (in godot.macos.editor.dev.arm64) (os_macos.mm:718)
[28] main (in godot.macos.editor.dev.arm64) (godot_main_macos.mm:77)
[29] 29  dyld                                0x0000000197653f28 start + 2236
-- END OF BACKTRACE --
================================================================

[Calinou]

I suggest we use a similar workaround as proposed in #54052, where we convert GPUParticles nodes to CPUParticles at load-time on macOS. This will break many particle effects, but it's better than crashing the engine or not having any particles show up.

In the editor, GPUParticles rendering will likely need to be disabled on macOS so you can still edit their properties (without affecting the saved scene file).

[SomethingWithComputers]

Still happening on 4.1.1 on MacOS Ventura 13.5.2 :(.

[xaqbr]

Still happening on 4.1.2. Is there no workaround we can utilize in the meantime without using a different machine?

EDIT: I guess setting the particle nodes as invisible works for the time being. You'll have to make them visible again at runtime.

[Calinou]

It might be worth checking if ANGLE fixes this issue: #72831

[dqdthanhthanh]

Still happening on 4.1.3 on MacOS Sonoma 14.1. Crash immediately when adding or editing GPUParticles node in compatibility mode. However it works normally on 4.2 beta 4.

[Calinou]

It might be worth checking if ANGLE fixes this issue: #72831

For future reference, ANGLE does fix this issue but it's no longer the default in 4.2.1 following #85785. (It was the default in 4.2 only.)

You can opt into using ANGLE in the Project Settings (Rendering Driver.macos). This may impact performance negatively though.

[jaekong]

It might be worth checking if ANGLE fixes this issue: #72831

For future reference, ANGLE does fix this issue but it's no longer the default in 4.2.1 following #85785. (It was the default in 4.2 only.)

You can opt into using ANGLE in the Project Settings (Rendering Driver.macos). This may impact performance negatively though.

I tried doing that but it still crashes the engine. (on 4.2.1_stable and 4.3_dev - master branch)

+ I don't know if it would help, but here's the error report from macOS error reporter.

[danneu]

Adding a GPU particles node also crashes Godot 4.2.1-stable with Driver.macos set to "opengl3_angle" on M1 macOS 14.2.1 (minor version increase from prev commenter).

https://gist.github.com/danneu/8cbe6c9f399f37dbbf4d5742e70cf0e5

[JanBeelte]

Happens to us also on M1 2021 macOS 14.2.1. Is there any short-term resolution to unblock our team?
Thanks,
Jan

[Calinou]

Is there any short-term resolution to unblock our team?

You can convert GPUParticles3D nodes to CPUParticles3D by selecting a GPUParticles3D node then using the GPUParticles3D menu at the top of the 3D editor viewport. This has some limitations though (no support for custom particle shaders, attractors, collision or turbulence).

This could be done at runtime automatically, but it would also break visuals in a lot of projects (to the point hiding particles entirely may be preferable in some scenarios).

[JanBeelte]

Thanks for the suggestion.
Converting back to CPU is not really an option so I believe hiding is the only viable one.
The problem with hiding: It might work during game play but still poses a big issue during development in the editor. As soon as the particle scene is opened once in the editor it instantly crashes and there is no chance of even starting the project again on Mac. Any suggestion how we could handle this on the short-term until this bug is fixed?

[Calinou]

Any suggestion how we could handle this on the short-term until this bug is fixed?

Without modifying the engine source code, the only way to avoid this is to add emitting = false below the particle node in the .tscn file before opening the scene in the editor. This can't be done if the scene is saved to a binary .scn file though.

[elpozewaunig]

Any suggestion how we could handle this on the short-term until this bug is fixed?

You could also change the renderer to Forward+ or Mobile during development in your editor as those renderers aren't affected by the bug. Since you're using an M1 Mac, there shouldn't be any need for using the Compatibility renderer on your device. When you are building for whatever platforms you're targetting, you can then switch back to the desired renderer.

[clayjohn]

Just an update on this issue. It's something that we are looking into, but it looks like there will be no easy solution.

GPUParticles work fine on intel macs. On Apple silicon macs, they cause this crash (likely because Apple silicon devices don't have OpenGL drivers, they instead of a layer that implements OpenGL over Metal and apparently that layer is missing support for transform feedback).

The typical solution would be to use ANGLE to translate OpenGL to Metal so we don't have to rely on Apple's broken automatic translation. Unfortunately, the ANGLE over Metal variant has significant performance problems and leaks memory rapidly making it unusable. The ANGLE over OpenGL variant works much better, but doesn't solve this crash.

Our best option is to workaround the performance issues and leaks. We already have identified a workaround for the leak, but it requires significant changes and we aren't sure why they are necessary (godotengine/godot-angle-static#3). We need to investigate how to workaround the performance issues still.

Needless to say the Apple ecosystem is not friendly to devs who want to support multi-platform and/or older devices. :(

[jalder89]

@clayjohn thanks for the information on this!

With Apple's apparent new interest in gaming, do you think it would be worth submitting feedback to Apple dev support or another contact method for the issues that are clearly caused by a poor Apple implementation?

2023 was the last year that Apple officially sold Intel based products and all future Apple systems will be Apple Silicon. So I believe we can expect Apple Silicon and Metal to be the overwhelming majority of iOS and MacOS developer's rendering platform in the next 2-3 years.

I myself still have my old Intel MacBook Pro but I just switched to M3 Max. I can basically run Unreal Engine 5, Unity, and Godot with really good performance on M3 and I would greatly prefer the benefit of an all in one development platform vs needing to swap to my Intel Mac or RDP into my Windows machine when I'm not at my desk if I want to target web or compatibility for older hardware that requires the compatibility renderer.

[clayjohn]

With Apple's apparent new interest in gaming, do you think it would be worth submitting feedback to Apple dev support or another contact method for the issues that are clearly caused by a poor Apple implementation?

Unfortunately Apple has been quite clear that they have no intention of supporting OpenGL/WebGL.

Apple's interest in gaming only extends to gaming on devices that support Metal (and soon WebGPU for web gaming). The future for Apple devices appears like it is going to be Metal/WebGPU only.

Unfortunately, that means it is on us to find workarounds because we are the ones who care about supporting multi-platform and low-end devices.

[Calinou]

What you can do in the meantime is add a macos override to the Rendering Method project setting as follows, before adding any GPUParticles to the project:

After clicking Add, set the override's value to forward_plus or mobile. The project will look different than with the Compatibility rendering method (especially in 3D), but GPUParticles should work.

If you're importing an existing project that has GPUParticles in its main scene, edit project.godot with a text editor before opening the project in the editor to add the override by adding this at the bottom of the file:

[rendering]

renderer/rendering_method.macos="forward_plus"

If there's already a [rendering] section in project.godot, add renderer/rendering_method.macos="forward_plus" at the end of that section instead.

[nubunto]

just stumbled upon this and it is fixed in 4.3.dev6

[clayjohn]

I wonder if this PR #88816 is responsible. It aimed at resolving a crash for super low end android devices. But seeing as this was an odd driver bug anyway, its possible that they shared a common root

[clayjohn]

I just confirmed. This bug is fixed in dev6/master. Reverting #88816 re-introduces the crash.

So I can happily report that this issue is fixed by #88816 :)

[fershopls]

What you can do in the meantime is add a macos override to the Rendering Method project setting as follows, before adding any GPUParticles to the project:

After clicking Add, set the override's value to forward_plus or mobile. The project will look different than with the Compatibility rendering method (especially in 3D), but GPUParticles should work.

If you're importing an existing project that has GPUParticles in its main scene, edit project.godot with a text editor before opening the project in the editor to add the override by adding this at the bottom of the file:

[rendering]

renderer/rendering_method.macos="forward_plus"

If there's already a [rendering] section in project.godot, add renderer/rendering_method.macos="forward_plus" at the end of that section instead.

Thank you! this worked for me

[dankoster]

For anyone new to Godot like myself: As of late July 2024 version 4.3 isn't quite released yet but you don't need to build from source. Official 4.3 release candidate builds can be found here: https://godotengine.org/download/preview/

4.3rc1 fixes the issue for me.