Another NVIDIA Engineer Just Made His First Contribution To Mesa

[pal666]

Exactly. Do not look the gift horse in the mouth too closely.

since when novideo is gifting hardware?

[Guest]

We are still waiting for their big open source announcement they were talking about some time ago.

Our ghosts will be waiting a hundred years later, lol. Whatever plans they had were probably scrapped. Nothing really stopped them from announcing anything

Doing the work, maybe. Announcing, no.

[StillStuckOnSI]

Really you are missing it Vulkan 1.1 added multi-GPU support. This long term is be multi vendor multi-GPU support yes this does result in needing lots of the stuff that makes up MPI.

I don't mean multi-gpu compute on the same machine. Arguably Vulkan does a better job there than OpenCL. What I have not seen is synchronization across GPUs on multiple nodes (i.e. the kind of thing you have in a cluster). This is table stakes for most non-trivial scientific compute applications and a big part of why people suffer through using MPI in the first place.

The new features for OpenCL are going to appear where first?
https://www.anandtech.com/show/15746...ute-frameworks
Finally, even Vulkan itself is a potential project of sorts for the OpenCL working group. The reversions to the core specification mean that Vulkan/OpenCL interoperability have taken a step back, and the working group would like to push that forward. Ideally, OpenCL should be able to work within the same memory set as Vulkan, as well as import and export semaphores, all in an explicit fashion.

I guess you missed this "OpenCL working group" bit also explains why will not be able to push SPIR-V for vulkan straight into OpenCL at first because vulkan will come the newest generation of SPIR-V with OpenCL using a generation behind and only a subset long term. SPIR-V to vulkan does not have to have GLSL stuff think game world engines turns out there is a need for compute inside vulkan for non shader things.

Really what you have been missing is how the dialects of SPIR-V are planned to be related to each other.

Trust me, I read the article end to end more than once when it came out (and scoured the IWOCL presentations too, 2019 and 2020). Notice how all of this language is purely aspirational. Nothing like "we will do <x> by <date>", it's all "ideally" and "would like to". Instead, let's look at what's actually happened since April:

1. SYCL, the biggest champion of OpenCL SPIR-V, dropped it in favour of being a high level standard and punting device-specific codegen to each implementation. A big loss IMO, but hey NVIDIA/AMD weren't budging and people want to run their programs on real-world hardware.
2. Intel added SPIR-V support to OneAPI level 0...which only runs on their hardware. Might as well use PTX that point, you'll at least support more devices!
3. Intel added SPIR-V/OpenCL 3.0 support in their NEO driver...which doesn't help you with running code on any other hardware. Same problem as 2).
4. There has been essentially no news from the compute-focused Vulkan subcommittees (e.g. ML) since VK_NV_cooperative_matrix in 2019.

The long term picture Vulkan SPIR-V should be the everything and the kitchen sink OpenCL SPIR-V will be subset of what Vulkan has. So yes dumping vulkan SPIR-V with GLSL stuff into OpenCL should not work. But dumping OpenCL SPIR-V into Vulkan should in time. Yes needing newer features than current OpenCL has on a GPU it will be used Vulkan because that the working group for the new features.

There are a lot of advantages long term to have Vulkan take the lead here. Of course I don't see Nvidia being exactly happy with this.

Yeah, I think you forget how much NVIDIA has their finger on the trigger (remember who the Khronos president is) and underestimate how mired down the standards process is. If one bad actor (e.g. Apple) decides to not cooperate, you're SOL.

What's not to say SPIR-V won't succeed or that Vulkan won't be an integral part of it, but you have to remember that there has been mostly talk with little action. This quote (from July, so we've had 1/2 a year since) is a good example:

It will definitely help. NVIDIA has publicly stated that we are going to implement OpenCL 3.0. The fact that we can now begin to have much more flexibility in shipping the functionality that is relevant to our customers will help us implement more than we are currently able to do for our customers going forward.

Personally, I would love NVIDIA to support SPIR-V in OpenCL. I loved the results of that poll. I'm going to take that back to NVIDIA and see if that will help us support it. Of course, we already support SPIR-V for Vulkan. The gap is potentially not too big, but as always, it comes down to what our customers are asking for.

But the amount of goodness in the SPIR-V ecosystem that we have been talking about now is beginning to get pretty persuasive.

Now ruminate over how many NVIDIA customers are asking for SPIR-V in OpenCL 3.0. Yeah, not many. See how this gives them plausible deniability to indefinitely push back or drop it altogether under the guise of "not enough customers asked for it"?

There are people doing cool applications with Vulkan Compute and OpenCL out there. Support them, and don't give accolades to companies or standards organizations that don't put their money where their mouth is. God knows there have been enough empty promises made already, let's not incentivize them to make more.

[oiaohm]

I don't mean multi-gpu compute on the same machine. Arguably Vulkan does a better job there than OpenCL. What I have not seen is synchronization across GPUs on multiple nodes (i.e. the kind of thing you have in a cluster). This is table stakes for most non-trivial scientific compute applications and a big part of why people suffer through using MPI in the first place.

Really this is a case if you don't have synchronisation working right in a single node make it a cluster before that is done does not work well. Vulkan really does not need to have as part of doing across nodes synchronisation vulkan is the node level issue. Writing clustering instructions into SPIR-V would make SPIR-V horrible to process on a per node base.

https://www.khronos.org/assets/uploads/apis/2020-05-sycl-landing-page-02_2.jpg

SYCL is a forked mess. 3 out of the 4 forks have a SPIR-V backend.

SYCL, the biggest champion of OpenCL SPIR-V, dropped it in favour of being a high level standard and punting device-specific codegen to each implementation. A big loss IMO, but hey NVIDIA/AMD weren't budging and people want to run their programs on real-world hardware.

This is not right SYCL was always a high level standard. The bits about intel miss the 2 not Intel implementations of SYCL that include SPIR-V. Codeplay in particular. 3 out of the 4 implementations of SYCL are going forwards with SPIR-V backend.

I really do see opencl with SYCL remaining the multi node solution. Of course the SPIR-V backend of these are going to be a subset.

[StillStuckOnSI]

Really this is a case if you don't have synchronisation working right in a single node make it a cluster before that is done does not work well. Vulkan really does not need to have as part of doing across nodes synchronisation vulkan is the node level issue. Writing clustering instructions into SPIR-V would make SPIR-V horrible to process on a per node base.

Sorry, what? Cross node communication, data transfer and synchronization have nothing to do with SPIR-V or any other kernel representation. This is a platform/API level feature. CUDA/ROCM/oneAPI have this through nccl/rccl/oneCCL respectively, and all 3 + OpenCL can use MPI as well. Vulkan has no platform-level APIs for this. Full stop.

https://www.khronos.org/assets/uploa...-page-02_2.jpg
SYCL is a forked mess. 3 out of the 4 forks have a SPIR-V backend.

This is not right SYCL was always a high level standard. The bits about intel miss the 2 not Intel implementations of SYCL that include SPIR-V. Codeplay in particular. 3 out of the 4 implementations of SYCL are going forwards with SPIR-V backend.

That diagram is far too optimistic. This is what is actually supported:

• ComputeCpp only supports SPIR-V on Intel GPUs. AMD GPUs are SPIR only (not the same, incompatible) and require the old fglrx driver (requires kernel 3.19 and abandoned in 2016).
• triSCYL's SPIR-V support comes through POCL, which doesn't support SPIR-V on AMD dGPUs. It does support (some) NVIDIA GPUs, but at that point you might as well compile to PTX and save all the headache of translation issues + debugging.
• Intel supports SPIR-V across the board. Big whoop, you can run on integrated graphics or their non-existent dGPUs.

After wasting way too much time looking into all these for the past couple of years, I wish things were as nice as you put them. I want to have open, cross-platform GPU support with a sane intermediate kernel language. That's just not the reality of how things are now.

[jonwil]

NVIDIA will not open source its drivers (or release the firmware needed to allow Noveau to do power/clock management) for modern cards because the license for the blobs says "if you want to do workload xyz you need to buy our expensive workstation cards" and if Noveau (or other open source drivers) could run the hardware at full performance then you could use the far cheaper consumer cards and the open source stuff to do workload xyz.