Vulkan-Samples VS MoltenVK

Vulcan is a driver-level API. It competes with DirectX and OpenGL.

CUDA is a language you write kernels. It competes with OpenAI's Triton language.

Here's what CUDA looks like: https://github.com/tspeterkim/flash-attention-minimal/blob/m...

This is what Triton looks like: https://triton-lang.org/main/getting-started/tutorials/06-fu...

By contrast Vulcan looks like this: https://github.com/KhronosGroup/Vulkan-Samples/blob/main/sam...

(It's true to some extent that maybe you could use Vulcan shaders to write deep learning kernels, maybe? I'm not aware of anyone doing it though)

Hi, i'm looking into descriptor indexing and was looking at the Vulkan-Samples repo. I finally thought i understood how the set binding invalidation works (like a stack?). In the code below both the non_uniform_indexing pipeline and the update_after_bind pipeline use the immutable sampler descriptor in their fragment shader. But since the descriptor set = 0 is rebound, won't the immutable sampler in set = 1 from the "non_uniform_indexing" pipeline be "disturbed" and have to be rebound?

and see if it works.

[1] https://github.com/KhronosGroup/Vulkan-Samples/blob/main/sam...

In this new sample, we see how to incorporate the Vulkan extension VK_EXT_mesh_shader and introduce per primitive culling in a mesh shader. https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/mesh_shader_culling

Also beginner here, I think you can learn other's codes to get a better understanding of the API by learning how others can abstract these concept into higher level. They're many great projects out there like Google's pbr renderer filament https://github.com/google/filament, AMD's gltf sample https://github.com/GPUOpen-LibrariesAndSDKs/glTFSample and also as many suggested, the Sascha Willems's repos https://github.com/SaschaWillems and the official sample https://github.com/KhronosGroup/Vulkan-Samples

Another way I saw some projects start was by using example base classes (either Sascha Willems' implementations or the framework used by Khronos Samples).

https://github.com/KhronosGroup/MoltenVK

Translating between rendering APIs is not really the problem. The GPU design is more different than the API is.

Khronos maintains MoltenVk though, which is "official" as it gets: https://github.com/KhronosGroup/MoltenVK

...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), Microsoft doesn't support Vulkan either ;)

MoltenVK implements large parts of Vulkan on top of Metal for Apple systems. It isn't full Vulkan but it makes porting Vulkan games to OS X easier.

That's cool. Maybe I haven't thought enough about this. Let me check it out. FWIW it's this PR that you are referring to I think: https://github.com/KhronosGroup/MoltenVK/pull/1815/

For Metal specifically, they could adopt and contribute to Vulkan and get access to a lot more software. Right now you need to use a compatibility layer, and surely Apple could just support both APIs natively with much lower overhead. But they don't, because it nudges developers to stick to the Apple ecosystem instead of being able to support multiple platforms.

At the moment the most promising thing is MoltenVK (DX12 -> DXVK -> Vulkan -> MoltenVK -> Metal), but the development is not that quick mainly because there aren't tons of developer that works at the same time on the project. It's not actually a Metal related problem at the moment (they have a road map of things that they can be achieved with Metal 3 like Mesh shader and Geometry shader).

What you asked is already existed for at least 8 years. Yeah EIGHT years. It's called "MoltenVK". So far it's the only implementation of Vulkan for macOS. Basically it's a wrapper that runs on top of Metal API.