Announcement

Collapse
No announcement yet.

Vendors Including NVIDIA Talk Up New OpenCL Extensions For Vulkan Interop, NN Inference

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

  • Vendors Including NVIDIA Talk Up New OpenCL Extensions For Vulkan Interop, NN Inference

    Phoronix: Vendors Including NVIDIA Talk Up New OpenCL Extensions For Vulkan Interop, NN Inference

    Last Friday night we spotted OpenCL 3.0.9 with several new extensions included. Today The Khronos Group is formally announcing these latest OpenCL additions focused on Vulkan interoperability as well as neural network inferencing...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    If it is not able to render stuff in upcoming Blender it will do nothing.

    Comment


    • #3
      The days of OpenCL seem to be numbered. AMD is pushing ROCm mostly, Intel oneAPI and SYCL, Nvidia puts CUDA first and everything else far below. Application developers seem to acknowledge that state of affairs.

      Comment


      • #4
        Originally posted by ms178 View Post
        The days of OpenCL seem to be numbered.
        I disagree. Intel is still pushing OpenCL and it's great to see POCL and Clover making progress!

        I'll never forgive Google for banning OpenCL from Android devices. Prior to that, many mobile SoCs had support for it.

        What I wonder is why people make comments like yours. Do you have some vested interest against it? If you don't want to use it, then don't. I see no need to spread FUD.

        Comment


        • #5
          Originally posted by coder View Post
          I disagree. Intel is still pushing OpenCL and it's great to see POCL and Clover making progress!

          I'll never forgive Google for banning OpenCL from Android devices. Prior to that, many mobile SoCs had support for it.

          What I wonder is why people make comments like yours. Do you have some vested interest against it? If you don't want to use it, then don't. I see no need to spread FUD.
          Aren't you answering your own question here? It doesn't work on Android. Google doesn't like it.

          Separately, Apple also doesn't like it. Nvidia is half-hearted on desktop. Intel has a competing stack. Who knows what AMD wants but its serial missteps make it basically a peon player in compute.

          Khronos seems to be trying to keep this dying horse alive by hitching it to the Vulkan train but I have yet to see compelling evidence that this attempt at a unified cross platform compute API which had a decade to realise its aim, but failed to reach it, is still relevant.
          Last edited by vegabook; 19 October 2021, 12:19 PM.

          Comment


          • #6
            Originally posted by vegabook View Post
            Aren't you answering your own question here? It doesn't work on Android. Google doesn't like it.
            Huh? No, people had it working on Android, but Google made a strategic decision to take a page from Apple's playbook and push their own, proprietary RenderScript, instead.

            And because they don't like fragmentation in their Android phone market, they actively banned Android phones from even having it.

            Originally posted by vegabook View Post
            Separately, Apple also doesn't like it.
            Apple designed it. I think the issues isn't that they don't like it, but rather they found more value it pushing their proprietary Metal API, instead. Same reason they walked away from OpenGL and haven't embraced Vulkan.

            Originally posted by vegabook View Post
            Nvidia is half-hearted on desktop.
            FWIW, Nvidia added 3.0 support, which they didn't have to do. As mentioned in this article, they issued the following quote about the 3.0.9 release:

            “Now that we have shipped conformant OpenCL 3.0 drivers, NVIDIA is committed to evolving significant new functionality to benefit all OpenCL developers. We have created the External Semaphore and Memory Sharing extensions together with the OpenCL Working Group for efficient interop with new generation APIs such as Vulkan, adding to the deployment flexibility already available through OpenCL’s interoperability with OpenGL.”



            Make of it what you will, but it's disingenuous to pretend they're sitting on their hands.

            Originally posted by vegabook View Post
            Intel has a competing stack.
            It's not competing! It sits atop OpenCL. They didn't have to do it that way, but chose to embrace OpenCL and SYCL.

            This is why my next dGPU will almost certainly be Intel's DG2.

            Originally posted by vegabook View Post
            Khronos seems to be trying to keep this dying horse alive by hitching it to the Vulkan train
            WTF? Khronos is the standards organization, not the OpenCL technical committee. What happens to OpenCL is what the committee decides will happen, and that's made up of member companies. So, they added Vulkan interop because enough of them see economic benefit in having it.

            Originally posted by vegabook View Post
            I have yet to see compelling evidence that this attempt at a unified cross platform compute API which had a decade to realise its aim, but failed to reach it, is still relevant.
            Plenty of apps use it. I'm not going to try to change your mind, but you should think about why so many member companies are continuing to push it forward and why implementers are continuing to keep up with the new developments.

            Also, you shouldn't forget that your perspective is inherently narrow. It has embedded use cases, including on FPGAs, that might be a lot more widespread than you're aware. Many people are predisposed to think of consumer & enterprise as comprising most of the computing universe, while embedded quietly makes up the bulk of programmable solutions sold!

            Comment


            • #7
              Originally posted by coder View Post
              I disagree. Intel is still pushing OpenCL and it's great to see POCL and Clover making progress!

              I'll never forgive Google for banning OpenCL from Android devices. Prior to that, many mobile SoCs had support for it.

              What I wonder is why people make comments like yours. Do you have some vested interest against it? If you don't want to use it, then don't. I see no need to spread FUD.
              I very much concur with vegabook's analysis and I don't have any interest in the outcome apart from eagerly waiting for seamless GPGPU programming to take over the world. But that hasn't really happened yet, apart from some specialized apps for content creation but even there, specialized hardware is more effectively used (at least when talking about video encoding, but OPTIX is also doing a better job in Blender and where it is supported). It is all about results in the end for me, and OpenCL didn't get me that far in my everyday life.

              OpenCL was always promised to be the best vendor-neutral approach to GPGPU programming, but as OpenCL was stuck at 1.2 for far too long, all the great features of 2.0+ haven't seen much use anyway and the vendors kept cooking their own thing with a higher priority. POCL and Clover are still miles behind feature- and performance-wise last time I checked and at least for me that rules them out for any serious use, Clover is still at OpenCL 1.1 (albeit recent MRs of 2.0 support were resurrected). And looking at the choices software vendors made recently, I very much doubt that there is still momentum behind OpenCL. Vulkan Compute/OpenCL merge might be Khronos lifeline and the morphed API might find some use in more varied applications that use Vulkan (which aren't that widespread, apart from some games).

              Comment


              • #8
                Originally posted by ms178 View Post
                OpenCL was always promised to be the best vendor-neutral approach to GPGPU programming, but as OpenCL was stuck at 1.2 for far too long,
                You mean the lowest-common-denominator was 1.2, for too long.

                Originally posted by ms178 View Post
                vendors kept cooking their own thing with a higher priority.
                True.

                Originally posted by ms178 View Post
                I very much doubt that there is still momentum behind OpenCL.
                Because it didn't coalesce the same level of support as OpenGL or Vulkan, it's always going to be just another option on the menu of GPU compute APIs. Still, the most portable and widely-supported option, by far. And that means it's not something we should dispose of, causally.

                Even if higher-level APIs catch on (e.g. WebGPU), they will still be implemented atop OpenCL, on some platforms. Again, I point to Intel's oneAPI as evidence of how much gas OpenCL has in the tank, so to speak.

                Comment


                • #9
                  Originally posted by coder View Post
                  It's not competing! It sits atop OpenCL. They didn't have to do it that way, but chose to embrace OpenCL and SYCL.

                  This is why my next dGPU will almost certainly be Intel's DG2.!
                  I thought Intel said that people could start using SYCL/DPC++ running over OpenCL but that their production stack would not normally run DPC++ over OpenCL.
                  Test signature

                  Comment


                  • #10
                    Originally posted by coder View Post
                    FWIW, Nvidia added 3.0 support, which they didn't have to do.
                    They kinda have to if they want their products to be more attractive to put in HPC builds where vendor-neutral production-ready is important.

                    Comment

                    Working...
                    X