Hacker News Reader

Comment by p1mrx | Hacker News Reader

How does using Vulkan for computation fit into the OpenCL/CUDA landscape? Is CUDA's proprietary nature doing meaningful harm, and does Vulkan help?

View on HN

You can run OpenCL kernels on Vulkan at least in theory: SPIR-V supports OpenCL memory model. CUDA might be machine translatable if you can compile into LLVM target (clang seems to have experimental support developed outside of Nvidia) which you then retarget into SPIR-V using a cross-compiler. The LLVM to SPIR-V cross-compiler however is limited in its translation for the time being.

In general, Vulkan is a thing which commands the GPU, but is not opinionated on what the language used to represent the kernel is as long as it compiles to SPIR-V. SPIR-V in itself is like parallel LLVM IR. If you look into the project source, the shaders are in GLSL which have been pre-compiled using a cross-compiler into SPIR-V. The C file you find on the project root constitutes as the loader program for the SPIR-V files.

Futhark project did some initial benchmarks on translating OpenCL to Vulkan. The results were mainly slowdowns. You can read about it in here: https://futhark-lang.org/student-projects/steffen-msc-projec...

We run OpenCL on top of Vulkan in a production application on Android, thanks to a project from Google / Codeplay and other contributors https://github.com/google/clspv. SPIR-V can't represent all of OpenCL, but maybe enough for most people's use cases.

Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted.

https://home.otoy.com/octane2020-rndr-released/

"OTOY | GTC 2020: Real-Time Raytracing, Holographic Displays, Light Field Media and RNDR Network"

https://www.youtube.com/watch?v=Qfy6CTaSHcc

I couldn't find any details about the migration on either links but it looks like they make massive use of Nvidia-specific features, so even with exactly the same performances it would make total sense to use Cuda just because the tooling is more mature.

The video presentation at GTC clearly discusses it.

They moved into Optix 7 as backend.

The video being almost two hours long, I'm not surprised I missed it when skimming. Do you know by chance at which point of the video it is discussed?

https://youtu.be/Qfy6CTaSHcc?t=932

Thanks. But I don't see how this fits with your previous statement:

> Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted.

They mostly talk about Vulkan+Cuda interop which isn't really supported, and they explicitly said they consider rewriting everything using Vulkan to get rid of this issue. So from what I understand, they are still pretty bullish on Vulkan, but it will require a lot of work and it will take some time (“but probably won't be this year”).

Optix doesn't do Vulkan and I doubt that NVidia will ever bother, and OTOY most likely will rather use they resources elsewhere like the new Metal render.

> and OTOY most likely will rather use they resources elsewhere like the new Metal render.

Maybe you're right, and this guy is wrong. But you gotta admit that contradicting the speaker of the video you're using as a source is unusual to say the least.

Apparently watching a 2h video is too much to ask nowadays, or am I now supposed to link all snippets and blogs from OTOY just to win a couple Internet brownie points?

> Apparently watching a 2h video is too much to ask nowadays,

Sorry if I don't spend 2h of my time watching a video presenting the features included in the new version of a piece of software I will never use, just so we have the same knowledge about this product. You generously posted a link to a part of this video relevant to our discussion and I'm thankful for that, but I'm also puzzled because the speaker contradicts you in this very snippet you chose!

Good day.

Reply on news.ycombinator.com