Godot freezes indefinitely when trying to open a project (Metal, MSAA)

[passivestar]

Tested versions

broken in 4.7 master
worked in 4.6 stable

System information

macOS Tahoe (26.2.0) - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M1 Max (Apple7) - Apple M1 Max (10 threads) - 32.00 GiB memory

Issue description

4.6	4.7

Steps to reproduce

Open the attached project

Minimal reproduction project (MRP)

starter_kit_3d_platformer_46.zip

upd: (If the above archive is broken, use this one: starter-kit-3d-platformer_46_2.zip)

[akien-mga]

broken in 4.7 master

Extracting the commit from the screenshot for clarity: 7dac0bc.

[bruvzg]

Reproducible with current master on macOS 26.2 in M4 Pro. Only reproducible with clean project, and not always, it seems to be import issue (bunch of threads stuck in cvtt::Internal::BC7Computer). I'll bisect it.

[bruvzg]

I'll bisect it.

It is reproducible with 4.6-stable custom build as well, so it's either a pre-existing timing issue only reproducible with debug builds, or it's BC7 compressor is just extremely slow with debug build.

[bruvzg]

Optimized build of current master loads project in the same time as 4.6 and works fine (no errors).
Debug build also works but takes about 3-4 minutes to load, so it's just debug build performance issue.

Edit:

no errors

There's single ERROR: Bug: Dictionary::operator[] used when there was no value for the given key "colormap". Please report. in the log, but it's the same in 4.6.

[akien-mga]

There's single ERROR: Bug: Dictionary::operator[] used when there was no value for the given key "colormap". Please report. in the log, but it's the same in 4.6.

Yeah I reported this in #115899.

---

I'm mostly wondering about the "timeout waiting for fence" Metal error which seems like a bug, even if the root of the problem is just a slow import due to lacking optimization.

As for the slow import without optimization, it's worth looking into to see if there are some low hanging fruits to restore some usability also for engine contributors. I had a similar issue during the 4.6 cycle which turned out to be a regression (#113172). Some options:

• Profile what's so slow and try to do some manual optimizations to avoid the most pathological cases.
• Force a minimal optimization level for the relevant code (e.g -Og or -O1 if it's enough to resolve most of the performance issue).
• Default dev_build=yes to optimize=debug (-Og) instead of optimize=none (-O0). The main reason to use none is for compilation speed, so this should be benchmarked to see what's the tradeoff between compilation speed, debug information available for debuggers, and performance.
• If the issue is in thirdparty code, we could also consider forcing a minimal optimization level on all thirdparty code, as it's quite rare that we want to debug issues in those libraries. It could default to -O1 or even -O2.

[bruvzg]

I'm mostly wondering about the "timeout waiting for fence" Metal error which seems like a bug, even if the root of the problem is just a slow import due to lacking optimization.

I was not able to reproduce this with any version, only long load time.