3 ms·
Given the replies, seems overwhelmingly it's about the software interface rather than the hardware. I'd got the impression that Vulkan would bridge that gap, b
by ricardo81 6y ago
Given the replies, seems overwhelmingly it's about the software interface rather than the hardware.
I'd got the impression that Vulkan would bridge that gap, but it's quite a low-level API and verbose. Would be interesting to hear comments on that, perhaps just for the case of the hosted GPU market being more competitive.
- BadInformatics 6y agoThere have been a few discussions on what Vulkan needs to be competitive for GPGPU programming. https://news.ycombinator.com/item?id=22880502 https://news.ycombinator.com/item?id=22880502 comes to mind. I would also note that multi-gpu distributed synchronization (especially across nodes) is a big part of enterprise CUDA usage and doesn't seem to be well-supported in Vulkan.
- pjmlp 6y agoNot really, although off topic, one of the sessions at GTC 2020 was how Otoy gave up on Vulkan for their Octane Render, and decided to use CUDA instead, when Optix 7 added CUDA based rendering support. Vulkan also suffers from being too late to the game. NVidia moved CUDA into a polyglot runtime early in the game (around version 3 I think), and took a 10 year effort to redesign the hardware for optimal mapping to C++ memory model. Vulkan might eventually get it via SYCL, now that SYSCL has turned into backend agnostic mappings for C++ heterogeneous computing. But even if SYSCL turns out to be adopted across the industry, Vulkan will just be another backend alongside CUDA, Rom, FPGAs,....