I don’t know how many of you use a Mac with Apple Silicon when using Godot, but I’ve noticed huge performance gains in Godot 4.3 Standard (GDScript) after installing the latest Mac OS Sequoia 15.1.
In general both my CPU and GPU load had dropped by nearly 50% just by installing the latest Mac OS. Obviously they are learning how to better control their hardware, it was always going to take a little time, when completely changing architecture. I haven’t reinstalled Godot just done the OS update.
I know the Godot team is working toward a native Metal renderer, but forward + and Vulkan on metal is just brilliant.
Clearly my project is very different from others but it’s nice to see a positive improvement just by a service pack install.
Sounds good. The last time I did a major update on MacOs it was a disaster and I had to revert.
I currently have 14.5 installed on a Macbook Pro with an M2 Max processor.
Improving performance would of course be nice.
Sorry to hear that. I have worked with and for Apple/Unisys for over twenty years, doing all sorts of technical roles, though never in a retail store, except once in Hawaii when I was on holiday (strange story). In all that time and since I have never had a problem during an update.
In my experience with troubleshooting faults for clients most issues occurred due to lack of disk space.
I’ve never been able to fill any hard disk I’ve ever had, guess I don’t hang onto stuff as much as others, I’ve only used 57gb on this 512gb machine including the OS and all the Apps. This machine is a Mac Studio with a M1 Max processor, it’s an amazing machine.
Sounds like you had an exiting career. Hope you don’t get me wrong. I really like my Macbook pro. I bough my first PowerMac 2002 just shortly after seeing Steve Jobs on a show in Paris.
The report about your update sounds ensuring and I will try to make the update one of these days.
You are right!! Just installed the release version of 15.2 which came out today, Graphics and CPU performance have dramatically increased in my project with Godot 4.3, while both CPU / GPU time and load percent have decreased.
Very impressed. Can’t want for 4.4 stable and the native Metal renderer.
While performance has never been a problem directly on my MacBook Air M1, I found that Godot’s editor had an annoying lag: Anytime I would switch away from it into another app and then go back (just by clicking into the editor window), it would take up to 2 seconds before becoming responsive again.
My game is running at >200FPS and the CPU Load of Godot is 4%, which means I wasn’t looking at a resource problem here.
Ultimately, I found that changing the setting “Enable Continuous Update” in the editor settings solved the problem. The editor using more resources now, but toggling between the editor and other apps (including the running game to make changes) is now instant. Maybe it helps others.
I’ve only found this to be a problem if you’re using a display resolution that is not an evenly divisible factor of the LCD panel resolution. If you go into display settings and you see the below scaled message then you are putting extra load on the GPU which can really affect performance, as every frame has to be non-uniformly scaled to fit your chosen display resolution. It can also not look as nice.
This is a problem on all Operating Systems, though I’ve never seen Windows or Linux inform you that you’re not using a resolution best suited for your display.
LCD screens are not like old CRTs they have a fixed resolution and using anything other than the panel resolution or and evenly divisible factor will affect performance.
Windows and Linux (X11/Wayland) scaling don’t work this way; they will actually use fractional scaling for the window contents. This means performance can’t be negatively affected depending on the scale factor.
macOS insists on using integer scaling and downsampling if the user requests a non-integer scale, which is the source of the performance issue when using a non-integer scale factor.
Still, doesn’t look as good as using the actual panel resolution or an integer divisible of it, hard to do factorial scaling when there are a fixed number of pixels, you can’t really have half a pixel.
There will still be a performance trade off, regardless of the method, due to the sheer fact that the scaling still has to happen.
All good though. I now understand the scaling used in Windows and Linux.
