OpenGL on the Mac is a problem that won't go away.
We've been complaining about it for years and years. It seems like Mac OS X OpenGL went into hibernation, for the most part, a long time ago. Occasionally new features would pop up, but it never kept up with the latest standards in recent years, and it was just...slow. Inexplicably slow.
My completely uninformed opinion has long been that the graphics team at Apple moved over to iOS and never came back.
But Apple introduced a new GPU API on their mobile platform that is more low-level, named Metal, and in Mac OS X 10.11, this moved over to desktops, too.
My entire Mac development life has been spent apologizing for low framerates on the Mac. Of course it doesn't beat Windows, where a ton of engineering and money went into Direct3D and the games were optimized for Direct3D by large teams of Direct3D experts...so when I putter in and smash down some equivalent OpenGL code as quickly as possible, of course it isn't competitive. But, I get asked a lot, how come the exact same OpenGL code is pretty fast on Linux?
Well, yeah. I've read this book before.
The nice thing about Metal is that it, at least in theory, maps pretty close to what real GPU hardware does in 2016, so my hope is that we're eliminating the concerns about non-performant drivers on the Mac if we write to Metal... instead of a ton of validation and emulation and resource management, mostly Metal just shuffles bits to the hardware, or at least I hope so. I'm hoping it removes the situation where you can write the most awesome rendering code ever and it just simply can't go as fast as you want.
And if it does remove the bottlenecks, it's worth time writing some Metal code, even for older games. Honestly, you get an Unreal Engine 2 and Unreal Engine 3 renderer, and you've covered almost my entire Mac back-catalog.
To experiment with the API, I wrote an SDL backend. This probably isn't something that would benefit performance-wise from Metal, because the bottleneck here is SDL's API, which wants to push small batches of vertex data on every draw call instead of building static vertex buffers up front. It's also not complete, but it is enough to run SDL's testsprite2 demo. I don't know if it's worth putting in revision control, so I'm posting the patch here for now, for people that are curious. Grab it.
My next step is going to be trying to move a whole game over to Metal to see if it works miracles.
To that end: MojoShader now outputs Metal shading language code. That patch is here. This is just a quick way to figure out how to get existing Direct3D shaders up and running on Metal. They'll still need to be compiled, but you can either do that at runtime (like GLSL), or offline ahead of time (like Direct3D).
One interesting note: The incomplete but largely usable SDL2 Metal renderer is 760 lines of code, plus a handful of lines worth of shaders. 1000+ lines into an equivalent Vulkan renderer and I'm still nowhere close to being able to draw something on the screen. Metal gets up and running faster, probably because it offers fewer options, doesn't have to worry about non-Apple platforms, and wraps a lot of the boilerplate in convenience functions. I'll report back when I spend more time with Vulkan.
--ryan.