Announcement

Collapse
No announcement yet.

Another NVIDIA Engineer Just Made His First Contribution To Mesa

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

  • #21
    Originally posted by mdedetrich View Post
    Agreed, it wouldn't surprise me if there are legal hurdles but basically if NVidia hires a new team/members that don't interact with the old driver team its a lot easier to provide that it was a clean room implementation/contribution.
    The point here is they already have a team.
    Unlike most of the NVIDIA commits we see to Mesa that are around Tegra support, EGL code, or other common bits

    Yes those working on Tegra as in Nvidia arm embedded drivers in mesa are already a clean room team. Not saying that embedded team to support more cards directly by Nvidia would not require more team members assigned to it.

    Please also note Nvidia has not been putting the resources in the clean room/Tegra team last few years either due to the light amount of work instead because they have been working on other projects for Nvidia. This is partly why the Linux world has just said repeatably to Nvidia just release a GBM driver they have a team they just have to give that team hours to work on stuff with the access to ask the need questions some that may need to go past legal to be answered(amd process).

    Yes the 5.9 shot by the kernel into Nvidia might have made Nvidia see that they need to make non closed source kernel driver route workable for the compute route at least because other wise they will be risking market share.

    Comment


    • #22
      Originally posted by piotrj3 View Post
      First Vulkan compute does not replace OpenCL, true for most stuff you can use Vulkan Compute as replacement and it will be better....
      But you need first to make all libraries/tools/support for Vulkan. That is biggest reason why CUDA also wins vs OpenCL, but Vulkan has almost nothing there.
      Vulkan is actually harder mostly.
      Adaptation of industry is slow (people will abuse whatever is existing to speed up development process).
      what you do not unterstand is this: most people do not use OpenCL directly they use a OpenCL working kernel... means they do not send task directly to the openCL API instead they send it to the OpenCL working kernel and this kernel translate it to OpenCL API calls.

      and this is the reason because you can switch this to vulkan you do not have to rewrite all the code to use vulkan directly you can rewrite just the working kernel to talk to the vulkan API instead of openCL.

      as soon as this is done you see many openCL projects switch directly to vulkan not because of a complete rewrite but because they chance the working kernel talking to vulkan instead of openCL.
      Last edited by Qaridarium; 08 January 2021, 11:01 PM.
      Phantom circuit Sequence Reducer Dyslexia

      Comment


      • #23
        Originally posted by Qaridarium View Post

        what you do not unterstand is this: most people do not use OpenCL directly they use a OpenCL working kernel... means they do not send task directly to the openCL API instead they send it to the OpenCL working kernel and this kernel translate it to OpenCL API calls.

        and this is the reason because you can switch this to vulkan you do not have to rewrite all the code to use vulkan directly you can rewrite just the working kernel to talk to the vulkan API instead of openCL.

        as soon as this is done you see many openCL projects switch directly to vulkan not because of a complete rewrite but because they chance the working kernel talking to vulkan instead of openCL.
        Vulkan kernels are generally written in GLSL/HLSL and compiled to SPIR-V. This is fed to the actual driver APIs.

        OpenCL kernels are generally written in a custom dialect of C(++) and compiled directly to a binary. It is possible to compile to SPIR-V as of recent versions, but barely anyone supports it (only Intel and now Mesa).

        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). Yes projects like https://github.com/google/clspv exist, but they come with a long, long list of caveats and still require work to port all but the most trivial of programs.

        ...and this is just device-side code execution. Last I checked, Vulkan had zero support for cross-machine operations a la MPI.

        I do think Vulkan compute is promising, but it's got a long way to go before a large number of people are going to use it for serious work. Even if a complete rewrite isn't required, a 75% rewrite is already bad enough. And that's assuming you even have the expertise or time/money/patience to deal with bleeding-edge drivers and non-existent libraries to begin with.

        Comment


        • #24
          Originally posted by Qaridarium View Post
          also in compute soon we will have Vulkan compute everywhere and OpenCL and CUDA will be death.
          some people even work on many OpenCL kernels to make them run with vulkan instead of openCL.
          Because of this apple already mark the OpenCL support as legacy means they drop it.
          This makes no sense at all. You're just saying that Apple marks OpenCL as legacy because of Vulkan compute… but Apple does not support Vulkan at all to begin with. 🤦‍♀️

          Vulkan (and Vulkan compute) is less supported by Apple than OpenCL, it's even not considered obsolete by Apple, Apple just does not consider it at all.

          You're just making a mash-up of various ideas that sounds close to you and gives the illusion of believing something, but you forget to check the rationality of it.

          Comment


          • #25
            Originally posted by illwieckz View Post
            This makes no sense at all. You're just saying that Apple marks OpenCL as legacy because of Vulkan compute… but Apple does not support Vulkan at all to begin with. 🤦‍♀️
            Vulkan (and Vulkan compute) is less supported by Apple than OpenCL, it's even not considered obsolete by Apple, Apple just does not consider it at all.
            You're just making a mash-up of various ideas that sounds close to you and gives the illusion of believing something, but you forget to check the rationality of it.
            for me vulkan is the same as metal is the same as DX12 is the same as mandle is the same as WebGPU
            ...
            these 5 are just the same. there is no relevant big difference

            if you have vulkan compute you can run it on metal to and you can run it on WebGPU to.

            "WebGPU is the working name for a future web standard and JavaScript API for accelerated graphics and compute, aiming to provide "modern 3D graphics and computation capabilities". It is developed by the W3C GPU for the Web Community Group with engineers from Apple, Mozilla, Microsoft, Google, and others.[1]"
            https://en.wikipedia.org/wiki/WebGPU

            as you can see... apple support Metal and WebGPU... but it is the fucking same as DX12 and Vulkan.
            Phantom circuit Sequence Reducer Dyslexia

            Comment


            • #26
              Originally posted by piotrj3 View Post

              First Vulkan compute does not replace OpenCL, true for most stuff you can use Vulkan Compute as replacement and it will be better....

              But you need first to make all libraries/tools/support for Vulkan. That is biggest reason why CUDA also wins vs OpenCL, but Vulkan has almost nothing there.
              Vulkan is actually harder mostly.
              Adaptation of industry is slow (people will abuse whatever is existing to speed up development process).
              Yeah this is the thing, people don't realize that the reason why almost everyone uses CUDA is because of the ecosystem, libraries and support. Most data/AI scientists+programmers don't give a shit about open source (let alone "proper" programming), their attitude is that they just want to get the job done.

              Comment


              • #27
                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.

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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.


                    Comment


                    • #30
                      here goes novideo opensource news: one patch. they kept their word

                      Comment

                      Working...
                      X