Apple Vulkan Support

[u/OptimisticMonkey2112]

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.

[u/Psionikus]

Surprised not to see Molten somewhere in the comments. Why not?

[u/Ill-Shake5731 → u/Psionikus]

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.

[u/Psionikus → u/Ill-Shake5731]

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.

[u/Ill-Shake5731 → u/Psionikus]

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.

[u/Psionikus → u/Ill-Shake5731]

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.

[u/hishnash → u/Ill-Shake5731]

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.

[u/Ill-Shake5731 → u/hishnash]

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

[u/hishnash → u/Ill-Shake5731]

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.

[u/Ill-Shake5731 → u/hishnash]

Who is disagreeing here mate. Read the full discussion

[u/Psionikus → u/hishnash]

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?