4 ms·
Huh, I missed the discussion in https://news.ycombinator.com/item?id=22902274 https://news.ycombinator.com/item?id=22902274 but while prefix-sum makes for a rea
by boulos 7y ago
Huh, I missed the discussion in https://news.ycombinator.com/item?id=22902274 https://news.ycombinator.com/item?id=22902274 but while prefix-sum makes for a reasonable microbenchmark, I think it misses my main problem with any of the existing !CUDA attempts: ergonomics.
The Vulkan Compute attitude towards device memory deeply confuses me. That is, for both OpenCL and Vulkan Compute, there is no way to say (AFAICT / at least a couple years ago): "I wish to allocate X amount of memory on this device, do not spill to the host; fail if you cannot satisfy". For most programs, it's probably a fine assumption, just like virtual memory for a regular program. But in a world where you're trying to push a system to the limit, you'd still like to say "No, I'm serious".
Raph: What's your take on the ergonomics of using Vulkan Compute? I'd hoped to see more on that given your opening of:
> Vulkan might be a viable platform, for a sufficiently persistent implementor.
- raphlinus 7y agoMy take is that ergonomics are pretty bad, there's a significant learning curve. But I'm also hopeful that it's possible to build tools that layer on top of Vulkan - unlike CUDA, which is a highly integrated toolchain and runtime, Vulkan really only targets the lower levels of the stack. I can't speak to your memory allocation question, as I'm personally quite happy with the default behavior.
- pjmlp 7y agoGiven that CUDA has a thriving eco-system of programming languages targeting it, I fail to see how it is not possible to build tooling on top of it.