Closed falconepl closed 1 year ago
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.
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:
OS: Fedora 36 CPU: Intel Core i7-6700K @ 4.4 GHz RAM: 2×16 GB DDR4-3000 (dual channel) GPU: NVIDIA GeForce GTX 1080 (NVIDIA 510.68.02) SSD: Samsung 850 EVO 1 TB
Using official Godot Linux x86_64 release binaries downloaded from TuxFamily. An average of 25 runs is performed.
Benchmark source and data files (CSV, JSON, Markdown) are available at: https://github.com/Calinou/godot-startup-times
editor_data/
and project folder are removed before every run.
editor_data/
and project folder are removed before every run.
The 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:
0 libsystem_kernel.dylib 0x7ff819438dba __abort_with_payload + 10
1 libsystem_kernel.dylib 0x7ff81943a877 abort_with_payload_wrapper_internal + 80
2 libsystem_kernel.dylib 0x7ff81943a827 abort_with_reason + 19
3 MTLCompiler 0x7ffa32221d4f fatalErrorHandler(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) + 635
4 libLLVM.dylib 0x7ffa31e86986 llvm::report_fatal_error(llvm::Twine const&, bool) + 323
5 libLLVM.dylib 0x7ffa31e869c0 llvm::report_fatal_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) + 29
6 libIGIL-Metal.dylib 0x7ffa295242dd IGILErrorMessageHandlers::reportUnsupportedFunctionReferenceError(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 42
7 libIGIL-Metal.dylib 0x7ffa2954532f (anonymous namespace)::BiFInliner::runOnModule(llvm::Module&) + 3877
8 libLLVM.dylib 0x7ffa31af3c15 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 559
9 libMTLIntelCompilerPlugin.dylib 0x10291acb9 MTLIntelCompiler::generateIGIL(llvm::Module*, MTLIntelFunctionType, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 669
10 libMTLIntelCompilerPlugin.dylib 0x10290fa3b MTLCompilerBuildRequestWithOptions + 523
11 MTLCompiler 0x7ffa3221276a MTLCompilerPluginInterface::compilerBuildRequest(bool, unsigned int, void const*, unsigned long, unsigned int, void const*, BackendCompilationOutput&) + 276
12 MTLCompiler 0x7ffa3220cd11 MTLCompilerObject::backendCompileModule(MTLCompilerObject::BinaryRequestData&, BackendCompilationOutput&, unsigned long long, std::__1::vector<CompileTimeData, std::__1::allocator<CompileTimeData> >&) + 159
13 MTLCompiler 0x7ffa322129f7 MTLCompilerObject::backendCompileExecutableRequest(MTLCompilerObject::BinaryRequestData&) + 517
14 MTLCompiler 0x7ffa32221658 MTLCompilerObject::buildRequest(unsigned int, unsigned int, void const*, unsigned long, void (unsigned int, void const*, unsigned long, char const*) block_pointer) + 258
15 MTLCompiler 0x7ffa321f822d split_stack_call + 13
16 MTLCompiler 0x7ffa32212cef MTLCodeGenServiceBuildRequest + 265
17 MTLCompilerService 0x1026d57e3 invocation function for block in MTLCompilerServiceHandleEvent(NSObject<OS_xpc_object>*) + 793
18 libxpc.dylib 0x7ff819191b70 _xpc_connection_call_event_handler + 56
19 libxpc.dylib 0x7ff819190956 _xpc_connection_mach_event + 1413
20 libdispatch.dylib 0x7ff81929b3b1 _dispatch_client_callout4 + 9
21 libdispatch.dylib 0x7ff8192b4041 _dispatch_mach_msg_invoke + 445
22 libdispatch.dylib 0x7ff8192a11cd _dispatch_lane_serial_drain + 342
23 libdispatch.dylib 0x7ff8192b4b77 _dispatch_mach_invoke + 484
24 libdispatch.dylib 0x7ff8192a11cd _dispatch_lane_serial_drain + 342
25 libdispatch.dylib 0x7ff8192a1dfd _dispatch_lane_invoke + 366
26 libdispatch.dylib 0x7ff8192abeee _dispatch_workloop_worker_thread + 753
27 libsystem_pthread.dylib 0x7ff81944efd0 _pthread_wqthread + 326
28 libsystem_pthread.dylib 0x7ff81944df57 start_wqthread + 15
It seems to me like it encounters an error, but fails to properly report it and crashes instead. reportUnsupportedFunctionReferenceError
is seems like the biggest hint to to the cause to me. I have not been able to attach to the process with a debugger to try to extract more info. (The process is a bit transient.)
While compiling it also emits [MTLCompiler] Error: undefined reference to `air_simd_is_helper_thread()'
to the system log. This happens more times than for the failing call though so I'm not sure it's related.
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.
Developers of the Dolphin emulator experienced some MoltenVK performance regression recently, maybe this can help https://dolphin-emu.org/blog/2022/09/13/dolphin-progress-report-july-and-august-2022/
There's a fair chance this issue is a MoltenVK bug, which we unfortunately can't fix on our end.
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. OS: macOS Monterey 12.6.1 (21G211)
arguments
0: ./bin/godot.macos.editor.x86_64
Current path: /Users/home/dev/c/godot
Godot Engine v4.0.beta.custom_build.dc4b61659 - https://godotengine.org
Vulkan API 1.1.224 - Using Vulkan Device #0: Intel - Intel Iris Pro Graphics
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 2):
Compiler encountered an internal error.
ERROR: vkCreateGraphicsPipelines failed with error -3 for shader 'ClusterRenderShaderRD:0'.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6848)
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 2):
Compiler encountered an internal error.
ERROR: vkCreateGraphicsPipelines failed with error -3 for shader 'ClusterRenderShaderRD:0'.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6848)
Only open the editor without arguments causes the question. If start it with a project, it works fine:
Editing project: /Users/home/dev/godot-projects/study-godot
arguments
0: /Users/home/dev/c/godot/bin/godot.macos.editor.x86_64
1: --path
2: /Users/home/dev/godot-projects/study-godot
3: --editor
Current path: /Users/home/dev/c/godot
TextServer: Added interface "Dummy"
TextServer: Added interface "ICU / HarfBuzz / Graphite (Built-in)"
Godot Engine v4.0.beta.custom_build.dc4b61659 - https://godotengine.org
Text-to-Speech: AVSpeechSynthesizer initialized.
Vulkan devices:
#0: Intel Intel Iris Pro Graphics - Supported, Integrated
Vulkan API 1.1.224 - Using Vulkan Device #0: Intel - Intel Iris Pro Graphics
- Vulkan Variable Rate Shading not supported
- Vulkan multiview supported:
max view count: 32
max instances: 134217727
- Vulkan subgroup:
size: 1
stages: STAGE_TESSELLATION_CONTROL, STAGE_FRAGMENT, STAGE_COMPUTE
supported ops: FEATURE_BASIC
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using present mode: VK_PRESENT_MODE_FIFO_KHR
Using "default" pen tablet driver...
Creating VMA small objects pool for memory type index 0
Shader 'CanvasSdfShaderRD' SHA256: c2b8e430fdb6bc4f9dae9edb9ece49ed09d5e1a0a72839e0b528693b38dc825a
Shader 'SkeletonShaderRD' SHA256: 49219ef3611affa34d8667e7d5e4e9b6cd590a574bb30a94d830339b7fa0f209
Shader 'ParticlesShaderRD' SHA256: 54d92ed371ee9c28fc72fcc586d3fe7da7293912dc78b205dcce92a9ed0b47a2
Shader 'ParticlesCopyShaderRD' SHA256: 02cc2dd608a6a366cda7ba880285d0496388a7a768ac3944d53bdb03e1571647
Shader 'CanvasShaderRD' SHA256: cd7448c742ea0f82dc39da02b3dcceae6a9056ec0511ee38b855d8b771955770
Shader 'CanvasOcclusionShaderRD' SHA256: 86f7bebdee38de285be45366523c21227ce5a7f2e96000cb877e8f3c8ba84394
Shader 'SceneForwardMobileShaderRD' SHA256: cbec962cb9e9757757c60b669bb5119901d09e7390eb067b44d4a428ba53b83a
Shader 'SkyShaderRD' SHA256: 23299e9bcb1dc738340eb8ff1ab9c45ba4098198f0b01a34494e4bd89158605a
Shader 'BokehDofRasterShaderRD' SHA256: f52d885ad3555dd177ac12bc9f8219b9194c00bb8ede87652f48ae75f93a3c00
Shader 'BlurRasterShaderRD' SHA256: 3dbe26b0efa519964415a64dcf3e59bf566741238929192b15530af79eea82f6
Shader 'CopyToFbShaderRD' SHA256: 0224e16dee0e0f9ebb10f0af3949bcd4aa4ce30a45442874a73edc8a006c95eb
Shader 'CubeToDpShaderRD' SHA256: e2651a294ae637b9467b915c975c23c80c352f9e625c0920c222e0333df2bff9
Shader 'CubemapDownsamplerRasterShaderRD' SHA256: a312c4287cb023c4beb6be334165c0a1c3f00bf38a7d26a39c34f707a175b0a1
Shader 'CubemapFilterRasterShaderRD' SHA256: 8383af97193f44c82a0479da18ac1e6bd1f10f4806877b0f675ae901f0207826
Shader 'CubemapRoughnessRasterShaderRD' SHA256: 32d1ed8b0757ac29e232f75197eead65b037d76642e0be2c7f3b844cbad5874b
Shader 'SpecularMergeShaderRD' SHA256: 16dbc1d4283379fc744d3e4fb0f716bf10b1435b3321de71baa09f22be07e618
Shader 'TonemapShaderRD' SHA256: acb166da64acd1fb5779aa07e138f1dc1bf18b23149a44e7de22530b0cab7bca
Shader 'VrsShaderRD' SHA256: b4c65272641e8295d9adc74feea3f0a3c28bf23633baacfb82513455dd918528
Shader 'LuminanceReduceRasterShaderRD' SHA256: 4232742a65afd9a9abb4b67aeec2ae15a6630015327d84f94c53ad4e06b96367
Shader 'SortShaderRD' SHA256: be96e5b562e2ae475d9cb09911d6521bbece783b980c743b15f90cc50eb81c8d
Shader 'BlitShaderRD' SHA256: 0628016b1d385dde0e65177688efbf6c7c0235fd9a936c23fd0ca5e52537a5fb
CoreAudio: detected 2 channels
CoreAudio: audio buffer frames: 512 calculated latency: 11ms
TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)".
CameraServer: Registered camera FaceTime HD Camera with ID 1 and position 0 at index 0
CORE API HASH: 516139552
EDITOR API HASH: 2976406307
Class 'DisplayServerMacOS' is not exposed, skipping.
Class 'EditorPropertyNameProcessor' is not exposed, skipping.
Class 'FramebufferCacheRD' is not exposed, skipping.
Class 'GDScriptEditorTranslationParserPlugin' is not exposed, skipping.
Class 'GDScriptNativeClass' is not exposed, skipping.
Class 'GodotPhysicsDirectSpaceState2D' is not exposed, skipping.
Class 'GodotPhysicsDirectSpaceState3D' is not exposed, skipping.
Class 'GodotPhysicsServer2D' is not exposed, skipping.
Class 'GodotPhysicsServer3D' is not exposed, skipping.
Class 'IPUnix' is not exposed, skipping.
Class 'MovieWriterMJPEG' is not exposed, skipping.
Class 'MovieWriterPNGWAV' is not exposed, skipping.
Class 'ResourceImporterMP3' is not exposed, skipping.
Class 'ResourceImporterOggVorbis' is not exposed, skipping.
Class 'SceneCacheInterface' is not exposed, skipping.
Class 'SceneRPCInterface' is not exposed, skipping.
Class 'SceneReplicationInterface' is not exposed, skipping.
Class 'UniformSetCacheRD' is not exposed, skipping.
EditorSettings: Load OK!
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 [MTLCompiler] Error: undefined reference to
air_simd_is_helper_thread()` is the closest to a detailed error there is. Unfortunately this is in internal proprietary code and not much to work with so that's a bit of a dead end.
However, with a bit of testing I figured out that what actually triggers this error is the usage of gl_HelperInvocation
in cluster_render.glsl:
In my case it's taking the non-USE_SUBGROUPS
path and removing those two conditionals (i.e. running the atomicOr
always) fixes the compiler failure and Godot starts fast.
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 : https://github.com/KhronosGroup/GLSL/issues/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 if (!gl_HelperInvocation)
branches in the non-USE_SUPGROUPS
paths should be okay. In those cases there is just a wasteful atomicOr as the Vulkan spec guarantees that atomics by helper invocations will not have an effect on actual memory
It would be helpful if you could test a version with the if (!gl_HelperInvocation)
branches removed on a moderately complex 3D scene (i.e. lots of lights and geometry). Errors should be pretty visible
In those cases there is just a wasteful atomicOr as the Vulkan spec guarantees that atomics by helper invocations will not have an effect on actual memory
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.
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?
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
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.
That would be fine as well!
Are there any useful benchmarking scenes readily available somewhere?
You can use https://github.com/Calinou/godot-reflection for this purpose :slightly_smiling_face:
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?
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 https://github.com/godotengine/godot/issues/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
@Ghashy See https://github.com/godotengine/godot/issues/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:
➜ ~ brew info molten-vk
==> molten-vk: stable 1.2.0 (bottled), HEAD
Implementation of the Vulkan graphics and compute API on top of Metal
https://github.com/KhronosGroup/MoltenVK
/opt/homebrew/Cellar/molten-vk/1.2.0 (134 files, 83.1MB) *
Poured from bottle on 2022-10-21 at 02:37:59
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/molten-vk.rb
system_profiler
data:
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.app
demo 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