Hacker News Reader

Comment by mschuetz | Hacker News Reader

The problem with the open standards is that their dev UX is absolutely horrible. You can't neglect usability, and then be surprised that there are no users.

View on HN

Note that Vulkan is only somehow better than anything else out of Khronos, because at least for that API someone is paying LunarG for the Vulkan SDK, and NVidia has a vested interest in now pushing slang as the shading language.

The moment LunarG no longer gets sponsored it will be back to "here is a standard, all the best, the community will provide the tools".

On the SYSCL front, that is mostly driven by Intel, and their own OpenAI tooling, there are hardly any offerings for SYCL from anyone else. Thus it is really only pseudo-open.

I wouldnt consider Vulkan any better in that regard. It's pretty damn terrible, UX-wise.

Consider that for the others you are supposed to build your own SDK from random pieces of libraries, not all of them playing well together.

In that regard, the Vulkan SDK is definitely an improvement.

However using Vulkan on Android is actually hardly any different, given that there is no SDK as such, only the libs and headers get dumped into the NDK, there is a github with samples from Google and that's it.

So bad that they failed to convince anyone to drop OpenGL ES from Java/Kotlin, and use NDK alongside C or C++ for Vulkan, thus now there is WebGPU implementation for Java and Kotlin consumption.

I do agree with the Vulkan code itself, related extension spaghetti, and overall state of drivers, which has become visible enough to have been part of Vulkanised talks for two years in a row now.

This is at the core of the matter for me, and my knowledge is too weak to understand why this is the case. I don't enjoy the idea of relying on Nvidia's stack for GPU compute, but the alternatives I've tried (e.g. Vulkan compute) are higher friction to use. I am trying to reconcile why; Nvidia shouldn't have this moat.

My software is labeled "CPU only unless using an nVidia GPU". I would prefer to strikethrough "nVidia". Incidentally, this means no more Mac support.

Vulkan compute is not really designed or intended to be a CUDA competitor, its feature set is much more restricted, and Vulkan host side code is much more verbose than CUDA. OpenCL or SYCL are much closer in features to CUDA. I found that when using SYCL on Nvidia, debugging symbols etc can be passed through and you can use tools like NSight Compute to profile it as if it were CUDA.

I tried getting LLMs to add proper Vulkan support to ik_llama.cpp, which have very good support for CUDA and CPU. The models do an admirable job; they don't care much about poor DX.

Few problems I noticed:

* coopmat2 from nvidia is the classic embrace, extend, extinguish. No point to ask the models to translate from CUDA to coopmat2. Instead, the models can understand the existing CUDA and CPU kernels, and adapt them accordingly to non-nvidia devices.

* However, the standard API is also lacking. The models struggled to make prompt processing compute-bound on strix halo when the graph is complex. Upfront standard API might just be an evolution dead end.

coopmat2 can be implemented by anybody non-nvidia. It's not EEE when the regular coopmat extension is not good enough to get good performance

From what I can tell, coopmat2 can get to about 75~90% of cuda performance on a single device, and there is no good way to do direct communication across devices. It is fair to say that nobody would replace cuda with coopmat2? That looks like a EEE project that can assigned to a couple of nvidia engineers, to fragment the ecosystem.

For reference: https://vulkan.org/user/pages/09.events/vulkanised-2025/T47-...

coopmat2 features will eventually be rolled elsewhere. coopmat also started as an NVIDIA extension.

The client use cases that coopmat was intended for are customer machines, not multi-GPU, which is broadly seen as a datacenter feature instead. That said coopmat orthogonal to this.

So when I said "a couple of nvidia engineers", I indeed meant Jeff.

VK_KHR_cooperative_matrix - embrace?

VK_NV_cooperative_matrix2 - extend?

I am pretty sure VkImportSemaphoreFdInfoKHR, mentioned in https://github.com/ggml-org/llama.cpp/issues/22648, works across multiple AMD devices, but somehow doesn't work across multiple nvidia devices.

> I am pretty sure VkImportSemaphoreFdInfoKHR, mentioned in https://github.com/ggml-org/llama.cpp/issues/22648, works across multiple AMD devices, but somehow doesn't work across multiple nvidia devices.

p2p is disabled on nvidia customer cards, vulkan device groups are shipped for the RTX 6000s

> Added support for creating Vulkan logical devices from multiple physical devices on select cards via VK_KHR_device_group_creation. This feature can be enabled by setting the environment variable __VK_ENABLE_DEVICE_GROUPS=1.

Back to the topic about cuda moat, in the slide with title "Problems with Coopmat1", the current frontier open models have absolutely no issue with:

* manual pipelining

* shared memory staging

* tiling

* bounds checking

A big problem there is ensuring performance portability between different GPUs

On the other hand, despite my complain about the standard API, the models were able to come up with cooptmat1 kernels that run dsv4 flash faster than whatever the guys at antirez/ds4 can come up with using rocm, on a strix halo, with the added benefit that I can also pair the strix halo with an egpu to drastically speed things up.

It could easily be a competitor to Cuda, if it just made things easier. Like, why does it take 50 lines of code to allocate memory in vulkan, and just one single line in cuda? Vulkan should just provide a single-line gpuMalloc convenience function. And not just for allocation, for all the other nonsense as well.

All commercial APIs have this moat, which is why other than Carmack famously advocating for OpenGL, the large majority of other devs never cared, they implement an API agnostic engine, use the best API for each platform, and move on with the rest of the game.

Even Carmack later admitted that DirectX had become much better than OpenGL, but they weren't going to change given the studio culture.

See https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...

Reply on news.ycombinator.com