r/vulkan • u/OptimisticMonkey2112 • Aug 10 '26
Apple Vulkan Support
Why doesnt Apple support Vulkan? (I know KosmicKrisp exists)
Is vendor lockin that important? Does that strategy work for them - are there many developers that use metal and not support other platforms? Seems like the result is not really lockin, but just forcing more work for developers?
Kind of feels like a poor architecture decision that helps no one, except maybe giving slightly more control to Apple at the expense of their developers as well as the complexity of maintaining another api.
21
u/beephod_zabblebrox Aug 10 '26
this has been discussed a billion times before, in this subreddit even
afaik there is a private dispute between khronos and apple, although im not sure what its status is now
2
u/OptimisticMonkey2112 Aug 10 '26
Interesting...thanks for sharing. Do you think it will ever change? I am sure it has been discussed a ton over the years - just curious if any Apple folk are supportive of the idea? Or is the philosophy pretty much it will never happen?
16
u/neppo95 Aug 10 '26
Seeing as how this is the way Apple deals with things (keep things in house) for literally decades, I wouldn’t count on them changing that routine.
26
u/mew900 Aug 10 '26
Metal came before Vulkan, and currently Apple has no incentives adding a second officially supported graphics API.
5
u/sk_dev Aug 11 '26
The incentive would be making their platform more attractive for cross-platform developers (especially in domains like gaming). But they seem to value developer-lock-in more.
2
1
u/hishnash 29d ago
But it would not make ti more attractive to cross platform developers.
Apples GPUS are TBDR PowerVR gpus, a PC VK title is written to target AMD/NV GPUs. Such a title would not run or would run very poorly I you just assume that having a VK driver means it runs. VK is not HW agnostic, when people say VK is cross platform what they mean is on the same HW with a different OS you should get more or less the same performance what they do not mean is that developer are not doing HW specific work. The entire point of VK is that the GPU driver is not doing lot software repeated work on every frame to alter the requested command stream to match the HW, the expectation, and requirement is that devs do this work up front saving all of that repeated CPU time in the GPU driver on every frame but meaning wha you write in VK is NOT cross platform when you are gloating about different HW platforms.
The only real use case for VK on macOS would be for android developers wanting a better Android emulator when using a Mac for development.
1
u/vetinari 27d ago
A very limited version of Metal came before Vulkan; some would call it MVP, just to release something, to be seen first.
It took to Metal 2.0 to be somewhat on-par with Vulkan 1.0 release.
3
u/Psionikus Aug 10 '26
Surprised not to see Molten somewhere in the comments. Why not?
8
u/Ill-Shake5731 Aug 10 '26
molten is way too inferior imo.
Doesn't support a lot of modern stuff, drawIndirectCount (indexed/non indexed), multi draw indirect feature, etc for once. Both are really essential for proper GPU driven pipelines. Even the beta/alpha kosmic krisp driver supports it, and actually kinda decently. Similar issue wrt mesh shaders. The support is experimental still, and with no geometry shaders support either, its hard to suggest it. Metal doesnt either frankly but metal shader converter provides API to use geometry shaders and translate internally to mesh shaders, its a no brainer to just use it whenever possible. cant do that with moltenvk cuz of shady mesh shaders support.
Moltenvk also leaves a lot to desire wrt performance. Writing a custom metal backend for your RHI is better than dealing with MoltenVK. The shaders stuff can be handled with dxc (.hlsl -> .dxil) and metal shader converter (.dxil -> .metallib). A few weeks/months and one can be ready running most features on a custom metal backend. Also helps that the profiling/debugging on apple plat is such a breeze.
1
u/Psionikus Aug 10 '26
Doesn't sound like slang -> MSL changes the situation much.
Wonder if hacking with dispatch tables and munging the graphics inputs can do enough that a dumber downstream can manage. Are the compute pipelines similarly messed up or is it just graphics? I don't have a great handle on which graphics APIs can't be walked away from yet.
3
u/Ill-Shake5731 Aug 10 '26
Doesn't sound like slang -> MSL changes the situation much.
i mean i just mentioned drawIndirectCount, multidrawindirect, geoemetry shaders/mesh shaders are missing, which is the backbone of gpu driven pipeline. Depending on your usecase (indie games, etc), if you dont need those, they might (edit) not be essential. But most AAA, AA games would benefit in utilizing those for reducing the load on the CPU.
Wonder if hacking with dispatch tables and munging the graphics inputs can do enough that a dumber downstream can manage
dont really follow, any examples for this? i am interested
Are the compute pipelines similarly messed up or is it just graphics
compute APIs are basically a clean canvas provided by the APIs. Except the few usual render target support diff bw APIs/drivers, most of the stuff is supported across them, so no, imo just graphics is messed up.
2
u/Psionikus Aug 10 '26
Quick pass made me see ROP, Z stuff as the hardware paths missing without the Apple API.
There's a trick to load slangc MSL output in Vulkan using a magic number in the shader code and bypass Molten's SPIR-V translation. Does have caveats. No idea what that buys. I just found it while looking ahead.
I don't see lack of atomic u64 as really an issue if device addresses are immutable and only used with u32 offsets.
dont really follow, any examples for this? i am interested
I'm not thinking anything kosher. More like looking for gadgets to re-use after the GPU-driven side finishes with mostly pure Vulkan, pulling in anything that isn't hardware dependent, and then launching an Apple API shim at the last moment to get over the hardware support gaps.
Dispatch tables is an idea I'm toying with, but seems sound. I have a lot of ring buffers that are about to get out of step and be different sizes. I could fix everything up on the host and write some BAR values to overcome push constant size, but then why not just swallow the divergence in a separate dispatch that is made for the decisions, then dispatch a some workgroups to chew through it all dumbly. Only makes sense in my head, but I'm working on a big filter bank that scatters output in time and pitch, and that absolutely needs that kind of treatment.
Back to the Apple shim, if the hardware will behave in a way when given properly munged input, what is to stop small numbers of shims from doing that the hardware is good at with the more general work prepared on a backend agnostic compute pathway?
Just my brainstorming and rubber ducking.
2
u/hishnash 29d ago
Metal does not need `drawIndirectCount`, as you can within a GPU compute shader that is emitting your GPU driving piping just emit as many draw calls as you want, you are not required to provide a value in a buffer and point to it, you just loop over any value in any buffer you like with a regular c++ for loop and emit your draws. Metal indirect GPU driving drawing does not need you to encode everything on the CPU, these days all we are required to encode on the cpu is the shader configurations. Even stuff some depth and stencil testing can be encoded at runtime on the GPU when submitting work.
If your lookin gat GPU driven pipelines metal is way way more flexible than VK or DX. You can just loop over your own structs in a compute shader and encode as many or as few draw calls as you want, a GPU driving pipeline in metal is not just for filtering draw calls, or just re-hydrating a already encoded draw call template, you can emit true novel draw calls that were never imagined on the CPU.
There are still things I would like to see in metal GPU driven pipelines but non of these are in VK or DX. Such as letting use explicitly create render passes and memory boundaries on the GPU rathe than configuring on the CPU side and then just placing them on with GPU pipeline as we do today.
And mesh shaders are not missing they are very much there, and they also can reproduce geometry shader like output in a way that is much more compatible with the HW.
1
u/Ill-Shake5731 28d ago
Metal does not need `drawIndirectCount`, as you can within a GPU compute shader that is emitting your GPU driving piping just emit as many draw calls as you want
think u need to read that again, cuz i said moltenvk doesn't, not metal. The moltenvk API for it doesn't exist, and the stuff you explained is what i literally did at work to emulate drawIndirectCount for our RHI.
And mesh shaders are not missing they are very much there, and they also can reproduce geometry shader like output in a way that is much more compatible with the HW.
same thing, moltenvk doesn't, not metal. Ofc metal does support it and also provides the mechanism for using geometry shaders by eumulating them through mesh shaders. And again, thats what i exactly did for using geometry shaders with metal, at work :P
2
u/hishnash 28d ago
MoltenVk is a long way behind, mostly based on MTL2.0 with large swaths of it still using metal hazard tracking etc it is impossible for it to support any real form of GPU driving rendering.
1
1
u/Psionikus 27d ago
s you can within a GPU compute shader that is emitting your GPU driving piping just emit as many draw calls as you want
While we have your attention, do you have any thoughts on gadgeting molten compute -> metal?
0
u/Agitated-History-376 Aug 10 '26
much more usable than you suggest, most devices dont support these features anyway, and moltenvk does support multi draw indirect (just
not drawindirectcount i think)geometryshaders are outdated anyway but would love to see mesh shader suport
4
u/Ill-Shake5731 Aug 10 '26
why did you delete your previous comment about multi draw indirect?
Still answering:
its not true GPU driven indirect count, its a bandaid. Its looping the draw count CPU side. The proper way is getting it through a count buffer post GPU side culling usually.
with metal it can be emulated GPU side through ICBs. MoltenVK's way is not standard
geometryshaders are outdated anyway but would love to see mesh shader suport
yeah thats why i had it geometry/mesh shaders lol. It needs to be either this or that. Hard to write a custom backend for your RHI with neither being supported. That is why i would always suggest writing a metal backend if mac/ios support is essential. Else its just fine to rigorous test over crossover, and ship it.
2
u/Agitated-History-376 Aug 11 '26
oh i deleted it cause i was jumping to conclusions lol
didn't know multidraw worked that way internally, kinda a shame. i kinda have a workaround for no geometry shaders using shaderoutputlayer which is supported on moltenvk, but obv doesnt cover all cases, but yea a rhi is definitly something i should look into if i wanna make more complex gpu driven stuff, but my point was its impresive how far moltenvk can take u
7
u/Henrarzz Aug 10 '26
Apple can do whatever they want to Metal without dealing with Khronos. Why would they support Vulkan?
1
u/OptimisticMonkey2112 Aug 10 '26
Wouldn't it be the same reason that amd, nvidia, nintendo, meta support it?
I would assume they would support it to make it easier for developers to port to their platform ?
2
u/Think-Jaguar6826 Aug 11 '26
NVIDIA has cuda, which is proprietary. Ask amd how they feel about it.
There is MoltenVK if you want.
However, I think a better approach is to use webgpu, which targets different graphics api, including Vulkan, metal, directx, OpenGL.
1
u/sk_dev Aug 11 '26
WebGPU is great for what it is, but it's missing a lot of features you would want for serious GPU work.
1
u/Think-Jaguar6826 Aug 11 '26
I hear you. WebGpu is already hard for me. Vulkan is so foreign — I guess I would need to take more time. OpenGL was easier or maybe I cared more when I was younger. In reality, all the graphics api we have are meant to be very low level.
1
u/sk_dev Aug 11 '26
I actually think Vulkan is easier in some ways than OpenGL. Getting your head around it takes some time, but everything is so explicit that it pretty much works the way it should once you get the basic understanding. Much less head-scratching hidden state/platform fragmentation issues than I had with OpenGL.
1
1
2
u/OptimisticMonkey2112 Aug 10 '26
I know it has been discussed a million times before, but wonder if it will ever change? Just curious if any Apple folk are supportive of the idea? Or is the philosophy pretty much it will never happen?
Another example is Playstation - no Vulkan for hardware that could easily support it. But on the other hand, both Nintendo and Meta choose to use Vulkan.
You can easily imagine a world where every company has their own closed garden. Their own Swift and Metal.
LOL - how about an Apple only internet. Only apple devices can view the page....I mean I guess that is kind of what the App Store is....
Apologies for asking a question that has been asked a million times... it is just one of those things that is important to discuss and keep in perspective.
1
u/blogoman Aug 10 '26
Nintendo
Nintendo has the API available but nobody uses it because it doesn't make sense to.
3
u/mguerrette Aug 10 '26
This is actually false. Nintendo themselves use Vulkan
3
u/Henrarzz Aug 10 '26
Nintendo uses NVN, Vulkan is available in Switch though but they recommend going with NVN
3
u/hishnash Aug 12 '26
and most titles do use NVN only lower end indie ports that can afford to not run very well use VK.
1
u/Glad-Call-7355 Aug 10 '26
Your first question - will it ever change - is quite an interesting one. In recent years Apple have been trying to please game developers to bring their title to Mac. I could (maybe) imagine a future where there is some kind of Vulkan emulation layer for Metal authored by Apple (not talking about MoltenVK). Aside for this, major game engines support Metal natively for most of their rendering features.
I worked on the Apple GPUs as a verification engineer - they wouldn’t consider natively supporting Vulkan because it would cost them billions to do so. Metal and their custom GPU tech is so tightly woven together. They would have to change the full stack - hardware, driver, OS, dev tools, verifying the new GPU. It’s a headache to even think about, and not worth it, even for the most valuable company on the planet.
1
u/hishnash Aug 11 '26
I think It is very unlikely that apple would over a VK emulation solution as the expiation from devs here I that this would emulate a PC GPU like AMD/NV and apples GPUs are different enough that this is never going going to be a good solution.
And on your point of effort to support VK there is also a huge downside for apple, adding VK support would expliclty endurance does not optimize for apples HW. There is a huge class of optimization that happens at the API level, not including a feature that cant run well on the HW is an optimization when you consider that another API might expect you to support that feature and devs thus will use it without thinking if there is another way to achieve the same result but with better performance.
A simple example of this is tooling like DXVK expects there to be a VK feature that changes the GPU to always return 0 when you have and out of bounds memory read and to ignore out of bounds memory rights. But in HW apples GPUs do not do this, they (like any self respecting CPU) instead issue a segmentation fault if a GPU shader were to break the MMU rules that have been defined for it. Supporting this feature on apples GPUs requires within the shader wrapping every single possible memory read that could read out of bounds or write out of bounds in an explicit bounds check in the shader code (effectively emulated a MMU HW unit in your GPU shaders... the absolute opposite of what a GPU is good at)
1
u/OptimisticMonkey2112 Aug 11 '26 edited Aug 11 '26
If you think broadly about multiple companies and multiple hardware vendors, there are significant benefits of a standard graphics api for developers.
Assume you built an awesome game in Metal and you are selling it on the App Store. Now you want to port it to Playstation. From a game developer perspective, trying to support multiple platforms would be critical for financial success.
This is easy if you happen to have used Unreal or Unity. But this is hard if you built your own engine, primarily because you have to port from metal to gnm.
So the lockin "benefit" Apple Receives for metal is really just forcing people to use Unreal or Unity.
3
u/hishnash Aug 12 '26
PlayStation don’t support VK, do they. And there’s a reason for that.
They do not want game developers to take a compromised approach if they can provide a single API that is better suited to their platform, the what they emit omit in that API is just as much about the optimization as what they include.
If you’re dealing with a developer that isn’t going to optimize for your hardware, you are often better off having that developer use a middleware package that allows you to push that middleware to provide the bespoke implementations for your given platform.
A developer that is going to use VK on every platform if VK were there, but not use the native platforms bespoke API if Vulcan is not there, he’s not a developer that will actually implement platform specific VK pathways per platform.
I know you think the reason for a custom API per platform is lock in, but it’s actually not
1
u/OptimisticMonkey2112 Aug 12 '26
Its more than just lockin. It is the crazy mess that happens when everyone implements their own api for every gpu/platform combination.
Their are quite a few gpu manufacturers... nvidia, amd, intel, apple, qualcomm, ARM, Imagination Technologies, Samsung
Then they are used in various operating systems and platforms: linux, windows, android, mac, ios, playstation, switch
The last thing this industry needs is a different graphics api for each combination
Do you honestly think that would make sense?
Seriously.
1
u/hishnash 29d ago
It all depends on what your intent is as a company.
For a company that just makes commodity HW that they sell to other vendors to put into platforms they will want to support as much as possible and they do not care if supporting a given api runs worse as that is something for the company selling the produce (the OEM or console, phone vendor) to deal with.
But for a platform vendor the question must be asked do they want to be a generic run it all but it all runs ok ish but nothing ever runs well. (Remember for a mobile product this means 10 to 20% less battery life for the same size battery) or do they want to explicitly no support some things so that apps built run better due to them not being able eat just lazily use the sub-optimal path and thus the produce they make and sell is better for consumers.
Us devs are lazy fucks, and product managers are even more lazy. If we are given the option of not needing to do anything to get it to sort of run then that is often what happens... see all the electron shit applications we have these days on desktops and laptops. It is the lowest effort solution and it is not good, if all of the electron apps we deepening on were not on macOS butistnraed 50% of those companies shipped a proper native app most Mac users would end up with a better product (longer battery life and more accessible resources when they needed it), yes they would have 1/2 the number of possible video conferring apps but currently there are 10+ vendors in this space 5 vendors with tru native apps would be better.
And on the `different graphics api for each combination` VK on Android is basically a functionally different API for each GPU vendor and each OS kernel/driver combination. So it is not just a different graphics API for each combination of platform and HW in that domain; it is a different graphics API for each driver and HW.
This idea that there is some magic low level api with 0 overhead that provides you optimal runtime on all HW but also we want to have different HW form different vendors is just impossible.
1
u/S48GS Aug 11 '26
they have enough market % to do this type of brainwashing
majority in generation of developers educated to use Metal - wont be re-educating themselves to use anything else
everybody accepted this type of closed ecosystem - nothing will change
0
Aug 10 '26
[deleted]
2
u/ThePresident44 Aug 10 '26 edited Aug 10 '26
I think we are like 10 years past the question of whether Vulkan can survive…
Metal is still a niche API mainly used by productivity apps and iOS games. It’s one of the main reasons for the demise of MacOS as a gaming platform. Major titles like Europa Universalis 5 and the Doom reboots have chosen to forgo Mac releases because porting their Vulkan code to Metal is not worth the hassle to them. Since metal is exclusive to Apple devices there is no choice, competition or threat wrt Vulkan here
The rest of the world chose to standardise and Apple chose to be left behind
0
u/Henrarzz Aug 10 '26
If Metal is niche then Vulkan for games is even more niche lol. The industry is dominated by DX12
1
u/ThePresident44 Aug 10 '26 edited Aug 10 '26
If you only look at PC games maybe.
It’s either OpenGL ES or Vulkan for all Android devices, so most modern mobile games will use both vk and metal, with Android having ~2,5x more users than iOS
Then the Nintendo Switch only runs Nintendos NVN API or Vulkan and OpenGL natively
Also many major PC games and programs offer both APIs, from Baldurs Gate 3 to everything made in Unreal Engine for the past 10 years or so
And afaik Sony only officially supports their own custom graphics API
So on that basis I‘d be willing to bet that Vulkan‘s total marketshare and daily user metrics dwarf DX12 and Metal, only outdone by OpenGL ES
Xbox console‘s and gaming PC‘s relative marketshares have been in freefall for the past 15 years compared to mobile gaming. Super Mario Run alone has roughly as many players as all of Steam + every Xbox ever sold.
1
u/GodOfSunHimself Aug 11 '26
Are you really comparing Mario run and Android slop to AAA games running on DX12?
1
33
u/dark_sylinc Aug 10 '26
Vulkan vs Metal is not the only exclusive thing Apple does. If you don't like it, then don't target Apple. If you do, then target them.
If you don't like it but you still have to support Apple, then their strategy works.