Hacker News Reader

Comment by Conscat | Hacker News Reader

Vulkan has some advantages to OpenCL. You gain lower level control over memory allocation and resource synchronization. Rocm has an infamous synchronization pessimization which doesn't exist for Vulkan. You can even explicitly allocate Vulkan resources at specific memory addresses, which means Vulkan can easily be used for embedded devices.

But some of the caveats for compute applications are currently:

- No bfloat16 in shaders

- No shader work graphs (GPU-driven shader control flow)

- No inline PTX (inline GCN/RDNA/GEN is available)

These may or may not be important to you. Vulkan recently gained an ability to seamlessly dispatch CUDA kernels if you need these in some places, but there aren't currently similar Vulkan extensions for HIP.

View on HN

The biggest advantage of Vulkan is that there are games relying on Vulkan, which means GPU drivers have to play nice with it. My impression is that OpenCL is borderline unsupported. In fact, there is an effort to reimplement OpenCL on top of Vulkan because the drivers are just that shit.

> GPU drivers have to play nice with it.

i would imagine nvidia to not want their moat with CUDA be uprooted, and so their vulkan support might get gimped in some ways (that does not affect games). At least, that is what the cynic in me would predict.

They don't have much to worry, Vulkan SPIR-V doesn't cover everything that PTX has, nor the ecosystem of compilers with PTX backend.

Nvidia have actually been putting a fair amount of work into their OpenCL drivers in the past few years and have a pretty decent implementation, I have a feeling that opencl is more widely used in the embedded space and they were kicked into gear

AMD, very recently have also been putting a bit more work into it, though their drivers are still the worst, and still way worse than their pre-rocm drivers

I work in VFX and I see that OpenCL has been used quite a bit in DCCs such as SideFX Houdini (which uses it extensively) and Foundry Nuke which uses it a bit too. Most of the GPUs are NVIDIA but there's some AMD too, and it's ability to fall back to the Intel (CPU w/vector instructions) host when running of the renderfarm, is absolutely critical as farm nodes generally tend not to have GPUs (most of ours don't even have X installed! So no hardware-accelerated OpenGL OR OpenCL is possible at all!)

Also one of my favourite non-VFX projects: 'Gollygang Ready' uses it to accelerate reaction-diffusion simulations.

I (perhaps naively) thought that OpenCL would still be a thing in a post-vulcan world.. SideFX are working on a new viewport using it.. I guess they solve different problems so can still coexist?

You don't need X to run OpenCL, only a driver. Pretty sure the same holds for OpenGL.

> No inline PTX (inline GCN/RDNA/GEN is available)

If I understand it correctly, that means the compute code is hardcoded into a specific assembly for gpu and to make it work with another card or newer one, you have recompile.

Like... Why? What is the problem with using SPIR-V, PTX or plain LLVM IR.

If we lived in a monoculture (e.g x86/64 for desktop apps), it would make sense, but there is a plethora of options and one gpu is not assembly compatible next gen.

"Inline PTX" is just PTX, and you have already listed PTX among the intermediate representations, which can be independent of hardware, because hardware-specific code will be generated when the program is loaded.

Of course, using PTX does not necessarily guarantee backward compatibility, because you may use some PTX features that are supported only on newer NVIDIA GPUs. Nevertheless, inline PTX should continue to work on future GPUs.

Perhaps by "hardcoded" you have referred to only a part of your quotation, i.e. to "(inline GCN/RDNA/GEN is available)".

In this case I agree with you, but even so, there are enough cases when it is impossible, at least with the current compilers, to obtain the maximum performance allowed by the hardware without using inline assembly language, either for GPUs or for CPUs. Therefore it is good for the high-level programming language to permit the use of inline assembly language, even if this facility should not be abused.

Inline assembly in shaders exists for basically the same reasons it exists in C++. Hardware gains new features much faster than Khronos standardizes an API for them in SPIR-V, so inline assembly lets you use of them ASAP. You might also want to make optimizations with the assembly if AMD/Intel's SPIR-V compilers aren't doing what you want.

Vulkan does make it easy to check which the feature availability of your device, and dispatch different shaders accordingly.

That said I've actually never had a reason to use inline assembly in shaders, personally.

Those are totally reasonable caveats to deal with currently. Thanks!

Shader work graphs are on the way https://gpuopen.com/gpu-work-graphs-in-vulkan/

Reply on news.ycombinator.com