A fully compliant Vulkan implementation for M1 would come with very surprising performance cliffs for a developer.

One of them: https://github.com/KhronosGroup/MoltenVK/issues/1244

And also potential optimisations that are not possible in other GPUs:

https://developer.apple.com/documentation/metal/gpu_features...

That's pretty common for TBDRs. The tile is rendered into a fixed size on chip buffer, and the driver has to split the tile into multiple passes to fit all of the render target data for nutty amounts of data coming out of the shader. PowerVR works the same way (completely unsurprisingly).

See this comment on that issue: https://github.com/KhronosGroup/MoltenVK/issues/1244#issueco...

It'd be surprising if an architecture had 0 such surprises and did everything Vulkan allows without any special performance considerations vs another architecture.

How about MoltenVK?

https://github.com/KhronosGroup/MoltenVK

It's fine, but it's frankly silly that you're forced to translate a free and open graphics API into a more proprietary one. Compare that to something like DXVK, which exists because Linux users cannot license DirectX on their systems. MoltenVK exists simply because Apple thought "let's not adopt the industry-wide standard for CG graphics on our newer machines". Again, not bad, but a bit of a sticky situation that is entirely predicated by technology politics, not what's actually possible on these GPUs.

Metal was released a year before Vulkan. Apple just didn't want to wait and decided to design their own better than OpenGL API.

Mantle was released ~1 year before Metal.

Proprietary to AMD, which gave it to Khronos when it was obvious they would do a second version of Longs Peak if left on their own.

Yet Vulkan, shows they cannot fix their love for extensions spaghetti.

DirectX was released a decade before Vulkan, that didn't stop manufacturers from including support for both so the user could decide for themselves.

You mean the support that is only possible because Windows backward compatibility still supports the OpenGL 1.1 ICD that they rely on?

Most of the time with crappy drivers that are a shadow of their DirectX ones?

> still supports the OpenGL 1.1 ICD that they rely on?

On Windows 11, it’s OpenGL 3.3 on top of DX12, because Qualcomm doesn’t provide an OpenGL ICD at all.

> crappy drivers

Special mention to the Intel OpenGL graphics driver on Windows. If you thought that the AMD Windows one was bad, the Intel one was somehow significantly worse.

With this gpu performance you’d think Apple might like to take advantage for gaming.

They already do, all middleware engines that actually matter, already support Metal.

Additionally iOS and Apple have much better tooling for Metal than plain DirectXTK/Pix, or that toy SDK from Khronos (that Google also uses on Android), if we compare vendor tooling.

Sounds like you don't need any help then, enjoy your 50-75% performance hit playing (a scant few) games through DirectX -> Vulkan -> Wine/Crossover ($30) -> MoltenVK -> Metal!

The games I care about enjoy native Metal and DirectX, and when I code anything graphics I don't use Khronos stuff, only on the Web, where there is no other option.

Any game dev gems have basic examples on doing an API loading layer.

Vulkan is mostly a Linux thing, and even the Switch has its own native API, NVN, it is not Vulkan nor OpenGL on the driving seat.

Here enjoy, https://www.ogre3d.org/

That’s not shown in terms of games people actually want to buy.

> It's fine, but it's frankly silly that you're forced to translate a free and open graphics API into a more proprietary one.

Thats exactly what every graphics API has done, because the underlying chip architecture is never free and open (and often, is neither).

If the issue is that you are targeting a proprietary intermediate API rather than bare metal, that is also how Nvidia's drivers work.

Is what is possible with Metal possible with GL though? Both in performance and features? They didn’t build Metal just to be contrarian.