Godot 4.5 Dev5 and later not working

[cero-numeros]

Tested versions

Reproducible in 4.5 dev5 and later
Not reproducible in 4.5 dev4

System information

Windows 10, AMD Phenom II X3 B75 (Heka), NVIDIA GeForce GTX 650

Issue description

Trying to launch godot 4.5 dev5 or later does absolutely nothing, even launching it with --verbose parameter.

Godot 4.5 dev4 works normally.

If it helps, my processor does not support AVX or SSE4.2 instruction sets.

Steps to reproduce

Launch Godot 😄

Minimal reproduction project (MRP)

N/A

[lawnjelly]

Likely due to #59595 .

So at the moment your choices:

• use Godot 3.x instead
• upgrade your PC
• compile Godot 4.x from source and remove the SSE4.2 flags

(Unless there is a change of heart on these flags, due to enough reports, so worth reporting.)

[Torguen]

Not long ago, the same thing happened to me. Godot, which had always worked fine, suddenly wouldn’t start. It turned out to be a bad connection with the controller through a USB cable. I had connected a USB extension cable — I unplugged it, and Godot came back. It’s probably not your case, but maybe it helps someone.

[Ivorforce]

Yes, this is definitely due to #59595. It was reasoned that it's unlikely that CPUs old enough to not support SSE4.2 are paired with GPUs new enough to support OpenGL 3.3. Unfortunately, your PC falls into this exact category. We're sorry about this, but it's unlikely the change will be reverted based on how few people this compatibility change affects.

If I were you, I'd probably continue to use Godot 4.4. It will be supported with bugfixes for a while longer, and should continue to work indefinitely even after that.

Another solution would be to switch to an AMD CPU from 2011 or later, or an Intel CPU from 2008 or later. Depending on your motherboard, this might be possible without upgrading any other parts. I appreciate though that this might not be possible in your situation.

[sanlor]

Would this mean that exported projects would also not work on these older CPUs?
Wouldn't it be better to at least throw some kind of error message?

[Ivorforce]

Would this mean that exported projects would also not work on these older CPUs?

Yes, builds created in 4.5 and later won't work on pre-SSE4.2 CPUs.

Wouldn't it be better to at least throw some kind of error message?

Yea, that would be good. It's a bit surprising to me that Windows doesn't do this by itself.

[lawnjelly]

Wouldn't it be better to at least throw some kind of error message?

Yea, that would be good. It's a bit surprising to me that Windows doesn't do this by itself.

The OS doesn't know in advance that the executable contains instructions not supported by the CPU, such a warning has to be explicitly coded. It generates a hardware fault the first "bad" instruction that is hit, which causes a crash rather than a user friendly error message.

Typically you would run CPUID instruction to get the CPU caps before using any of these instructions. You can do this when dynamically selecting codepaths according to support.

But we aren't doing this, we are explicitly telling the compiler "use SSE4.2 whenever you can", so there are several potential problems now:

• We aren't calling CPUID.
• We can't use any instructions / runtime library calls that might use SSE4.2 to output the error message.
• We need to do the above before anything else runs in the executable.

We can do the first, but the 2nd and 3rd may be difficult to achieve:

• Even doing dynamic selection of codepaths, preventing calls to higher SSE architectures leaking into other code is notoriously hard to do
• In c++, order of construction / destruction is not guaranteed, and at the moment we already have significant existing SIOF bugs.

That's not to say impossible of course.
You can also use e.g. a loader that checks this, but generally we prefer to release with one executable.

Grok suggests:

Step-by-Step Implementation

Use CPUID to Check SSE4.2 Support:

• The CPUID instruction with EAX=1 returns feature flags in ECX. Bit 20 of ECX indicates SSE4.2 support.
• Write a function to execute CPUID and check this bit.

Perform Check Early:

• Use a global object with a constructor that runs the CPUID check before main(). This ensures the check happens before any static initialization that might use SSE4.2.
• To avoid the static initialization order fiasco, ensure this object is defined in a way that it is initialized first (e.g., in a single translation unit or by controlling linker order).

Prevent SSE4.2 Instructions:

• Compile the CPUID check code without SSE4.2 optimizations (e.g., use compiler flags to disable SSE4.2 for the specific file or function).
• Ensure no inline functions or static initializers use SSE4.2 instructions before the check.

Display Error and Exit:

• If SSE4.2 is not supported, print an error message to stderr and call std::exit to terminate the program.

[ydeltastar]

The minimum system requirement needs to be updated.