> Is the "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" pipeline robust when it come to performance?

It's basically the same concept as Apple's Clang optimizations, but for the GPU. SPIR-V is an IR just like the one in LLVM, which can be used for system-specific optimization. In theory, you can keep the one codebase to target any number of supported raster GPUs.

The Julia -> Metal stack is comparatively not very portable, which probably doesn't matter if you write Audio Unit plugins. But I could definitely see how the bigger cross-platform devs like u-he or Spectrasonics would value a more complex SPIR-V based pipeline.

▲

Archit3ch 5 days ago | parent [-]

> The Julia -> Metal stack is comparatively not very portable

You can do "Julia -> KernelAbstractions.jl -> Metal", "Julia -> KernelAbstractions.jl -> CUDA", etc. if you need portability. This is already used by some of the numerical libraries in the ecosystem.

	▲	bigyabai 5 days ago \| parent [-]
		Sure, you could do that for any language/SDK if you're patient enough. You could scrap the abstraction layer altogether and litter the whole thing with ifdefs if you're really lazy. We're definitely going to see people using higher-level libraries to abstract all this away in the future though. We knew this was going to happen a decade ago, so it's been frustrating watching GPU standards fragment while featureset demands consolidate. Nowadays there is basically no upside to writing a raster program with native GPU libraries when you could target a higher-level standard with oftentimes better performance.