Prior to 2.0.14 being released, I wanted to compile on Apple Silicon for a demo I’m just starting working on, so I built SDL sources myself. Today I dropped in 2.0.14 instead of the sources I compiled myself and saw a massive performance degradation. I’m wondering if anyone has an idea why this might be (seeing an order of magnitude difference going from ~1000 fps to ~60 fps)? I assume 2.0.14 has built-in support for Apple Silicon since I don’t get a complaint about it, as I did with 2.0.12 (couldn’t use 2.0.12). Is it somehow possible that someone left a debug build on as the default for 2.0.14 for Apple Silicon or is it that I accidentally compiled a release version for myself and the development builds are always debug?
Thanks in advance.
PS I checked with lipo -archs on 2.0.14 and see it does indeed have arm64 as a native architecture. This probably should’ve been mentioned in the 2.0.14 release notes.
When you use the term “Apple Silicon” do you mean MacOS or iOS? Until very recently (i.e. with the release of the M1-based Macs) MacOS was x86-64 and iOS was aarch64.
I mean macOS. Obviously it’s been arm on iOS for all of time so there was no missing architectures there and need for me to compile it myself to begin with.
I don’t think this is vsync, since frames will vary between 4 ms and 30 ms. And I doubt SDL gets compiled with some sort of vsync by default. I just used the number 60 as an average.
I’ve noticed with my own stuff, even with SDL 2.0.12, I can’t get above 60 FPS (even with vsync supposedly turned off) if I’m compiling with the latest SDK and running on macOS Big Sur. When turning vsync off it ping-pongs between 120 and 30 and averages out to 60, but with vsync on it’s rock solid at 60 FPS (16.6… ms frametime). On the previous version of macOS the app could easily hit 400 FPS.
This is an app that’s just using SDL for window and input management and is doing its own rendering with Metal directly.
I’m wondering if there was a change under the hood in Big Sur that causes this.