Announcement

Collapse
No announcement yet.

Another NVIDIA Engineer Just Made His First Contribution To Mesa

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • jonwil
    replied
    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.

    Leave a comment:


  • StillStuckOnSI
    replied
    Originally posted by oiaohm View Post
    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.

    Originally posted by oiaohm View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by StillStuckOnSI View Post
    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/uploa...-page-02_2.jpg
    SYCL is a forked mess. 3 out of the 4 forks have a SPIR-V backend.

    Originally posted by StillStuckOnSI View Post
    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.

    Leave a comment:


  • StillStuckOnSI
    replied
    Originally posted by oiaohm View Post
    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.

    Originally posted by oiaohm View Post
    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.

    Originally posted by oiaohm View Post
    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:
    Originally posted by Neil Trevett
    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.

    Leave a comment:


  • sandy8925
    replied
    Originally posted by ms178 View Post
    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.

    Leave a comment:


  • pal666
    replied
    Originally posted by CommunityMember View Post
    Exactly. Do not look the gift horse in the mouth too closely.
    since when novideo is gifting hardware?

    Leave a comment:


  • pal666
    replied
    here goes novideo opensource news: one patch. they kept their word

    Leave a comment:


  • oiaohm
    replied
    Originally posted by StillStuckOnSI View Post
    They are "identical" already in that the structure of the IR is the same and both parsed identically. I don't think they'll ever be completely mutually interchangeable because of runtime mechanics, and the article certainly doesn't state as much either. Runtime interop does not imply being able to shove SPIR-V with GLSL stuff into clCreateProgramWithIL.

    Also, SPIR-V is an optional feature in OpenCL 3.0. I would not be at all surprised if NVIDIA just bumps the version number on their 1.2 implementation and re-releases it without adding SPIR-V support.
    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.

    Yes SPIR-V is a optional feature of OpenCL 3.0 its not a optional feature to all future Vulkan versions.

    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.

    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.

    Yes NVIDIA will be able to just bump there existing OpenGL driver. But going forwards as interop between Vulkan and OpenCL get shorted out and Vulkan comes the working group for new GPU compute features and with the final killer that to certify for new Vulkan version will mean having these features. Basically this is going to be drag Nvidia kicking and screaming as they are forced to generically support compute features instead of making them card exclusive.

    Lot of what you are talking about is current not where the roadmap says we are going. Yes this roadmap will see new version of OpenCL be full featured on day one of release on GPU by vendors who have kept up with their vulkan support. It also provided the advantage of having deployed and debugged these features in Vulkan before you are using them in serous compute with OpenCL.

    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.


    Leave a comment:


  • StillStuckOnSI
    replied
    They are "identical" already in that the structure of the IR is the same and both parsed identically. I don't think they'll ever be completely mutually interchangeable because of runtime mechanics, and the article certainly doesn't state as much either. Runtime interop does not imply being able to shove SPIR-V with GLSL stuff into clCreateProgramWithIL.

    Also, SPIR-V is an optional feature in OpenCL 3.0. I would not be at all surprised if NVIDIA just bumps the version number on their 1.2 implementation and re-releases it without adding SPIR-V support.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by StillStuckOnSI View Post
    Even then, OpenCL SPIR-V != Vulkan SPIR-V! The two dialects share some common operations, but each have mutually incompatible extensions and different runtime models. For example, Vulkan has extremely limited pointer manipulation whereas OpenCL is far more lenient (this is vital for compute).
    https://www.anandtech.com/show/15746...ute-frameworks

    This is yes and no. If you read the roadmap for GPU accelerated OpenCL the SPIR-V with Vulkan is going to come identical. So yes two slightly different dialects of SPIR-V at the moment with the plan to merge them into one. Will make vendor certification simpler so its run one test suite done for Vulkan and Opencl.

    Really I don't think long term Vulkan compute is really going to be a thing as such as instead it will be opencl on vulkan instead.

    Leave a comment:

Working...
X