11 ms·
Khronos Announces OpenCL 3.0
- pjmlp 7y agoSo basically, anyone that wants a modern language agnostic API for computing, with SDK and graphical debugging support for C++, Fortran, Haskell, Julia, .NET, Java, Python, should just keep using CUDA, business as usual. Because with the reset to OpenCL 1.2-derrived specification good luck with SYCL adoption, let alone anyone caring to write SPIR-V backends.
- VHRanger 7y agoExcept CUDA is proprietary and doesn't work on iGPUs and non-nvidia GPUs?
- pjmlp 7y agoAs proven by its adoption, like with 3D APIs, that isn't something that most people actually care about, rather eco-system and tooling.
- belval 7y agoThis is a fair point, but it isn't really a problem for most people. Nvidia GPUs aren't much more expensive than a matching AMD GPU for students/researchers. Once you get in the entreprise market, Nvidia is simply killing it with their low power consumption and low profile cards (P4/T4) so it usually isn't a problem and no one really care for the price difference.
- cesarb 7y agoThe parent comment mentioned iGPUs, which are commonly found on laptops or small computers like NUCs. If you're a student with a laptop or a NUC, "buy a new GPU" is not an option; you'd have to buy a whole new computer (and monitor if what you had was a laptop). That's a high barrier to entry.
- pjmlp 7y agoNot if they had an optimus to start with. Also Intel GPUs just suck at everything that isn't doing 2D GUI acceleration anyway.
- jjoonathan 7y ago> Intel GPUs just suck Can confirm. 8 bit floats. Yes, really.
- jfkebwjsbx 7y agoIntel GPUs are actually quite good for what they are, even for 3D. Not everything is AAA games.
- pjmlp 7y agoI though we were talking about high performance APIs here.
- jfkebwjsbx 7y agoYou can run Vulkan on Intel GPUs just fine. (Unless there are recent issues that I am unaware of, I don't follow why the mix between hardware and API).
- xnyan 7y agoStill proprietary, but compiles to AMD and x86 now as well as nvidia.
- fluffything 7y ago> Originally birthed by Apple and broadly adopted by the industry as a whole Do Apple and NVIDIA have good support for OpenCL ? EDIT: From the same article, further below: > Apple has deprecated OpenCL > AMD’s OpenCL drivers are a mess, > NVIDIA’s interest is tempered by the fact that they already have their very successful CUDA API,
- Iolaum 7y agoNot lately. Apple is deprecating it in favour of Metal and nvidia haven't been supporting well the latest 2.x versions nudging users towards CUDA.
- jai_ 7y agoApple has officially deprecated the use of OpenGL and OpenCL on it's hardware since MacOS 10.14 but maintains the implementations for continued use for now as they would like everyone to use their own Metal API. They are pinned at OpenGL 4.1 and OpenCL 1.2. OpenGL and OpenCL are still very mich supports by Nvidia and other GPU manufacturers, dependent on the OS. https://support.apple.com/en-gb/HT202823 https://support.apple.com/en-gb/HT202823
- Joeboy 7y agoSo IIUC this announcement is actually "We're going back to the last version of OpenCL that actually has cross-platform support". Which makes it seem a bit less crazy.
- deleted 7y ago[deleted]
- VHRanger 7y agoYou can still use openCL and openGL on Apple hardware through MoltenVK (the former because it compiled to SPIR-V)
- jfkebwjsbx 7y agoNo, MoltenVK is only for Vulkan, not OpenGL.
- hyperpallium 7y agoThe complete title was more informative: Khronos Announces OpenCL 3.0: Hitting the Reset Button on Compute Frameworks
- cm0000cm 7y agoand echoing a comment above, it's basically: "We're going back to the last version of OpenCL that actually has cross-platform support"
- pjmlp 7y agoSome cross platform, it was never supported on Android, and most likely never will be.
- cm0000cm 7y agoOpenCL is available in pixel 3 and pixel 4 phones, but I agree you can't count on it for all Android devices
- pjmlp 7y agoIf it isn't documented in https://developer.android.com/ https://developer.android.com/ it doesn't count. Using OpenCL custom drivers from OEMs requires ADB shell access and deployment of custom libraries, hardly something that any application on Play Store can count on.
- Joeboy 7y agoOver the weekend I dipped my toes into the GPU compute waters a bit, tried to get to grips with the massive tangle of competing and co-operating technologies, and tentatively concluded that OpenCL was probably as good a place as any to start learning, in 2020. Interested to hear opinions on whether that was a reasonable conclusion, and whether this makes a difference to it.
- skohan 7y agoIt depends what you need to do with it. If you're doing something like image processing or dealing a lot with matricies/linear algebra, Vulkan's compute support is quite good and the compatibility story is great, but GLSL/HLSL might not be ideal depending on your use-case.
- VHRanger 7y agoExcept Vulkan is a giant pain in the ass to set up. Just getting through the Vulkan tutorial is a weekend long affair.
- whatshisface 7y agoSurely once one person has gone through the Vulkan tutorial, everyone else can copy them?
- skohan 7y agoThe problem is that Vulkan's power comes from specificity: in other words you can plan your resources and executions for exactly your use case which gives great performance with little overhead. The trade-off is because everything is so hand-tailored, it's very difficult to generalize, so just copy-pasting an implementation is only useful if you want to do exactly the same thing.
- pjmlp 7y agoNo, Vulkan follows the learning path of OpenGL. Instead of having a nice SDK like the proprietaty APIs do, you are expected to go hunting for books and online tutorials about third party libraries so that you can go through all basic steps of loading shaders, textures, font files, gui frameworks and display something. Also in the process you will implement your own scene graph and material support. Consider it the rite of passage into Khronos' land, which every graphics programming student throughout the world has to go through. Yes, there is LunarG SDK, however it is quite anemic versus what VS + DirectXTK, XCode + MetalKit, PS4 SDK, Switch SDK offer as out of the box experience.
- edwintorok 7y agoMesa still hasn't implemented OpenCL 2.x ... now they don't have to. Although applications like Folding@home don't really work with OpenCL as provided by Mesa, so it'll likely have to be updated to work with the 3.0 ~= 1.2 version.
- jeltz 7y agoWould it make sense to add support for more compute stuff to Vulkan instead and move towards only having one framework which supports both compute and graphics, or are the tasks different enough for it to not be worth it?
- jfkebwjsbx 7y agoThis would have been way better. Khronos could provide a library on top of Vulkan to make things easy to use for users and easy to implement for vendors.
- skohan 7y agoI'm not sure if I understand what the value of a new OpenCL version is precisely. Is there anything you wouldn't get by just adding support for OpenCL programming language to SPIRV cross and executing kernels with Vulkan like any other compute shader?
- elbows 7y agoOne issue is that the Vulkan API is absurdly low-level and verbose. There are good reasons for this if you're writing a game engine, but if you just want to run simple compute kernel you're looking at ~500 LoC, probably an order of magnitude more than with OpenCL. So the barrier to entry is really high. It also seems the Vulkan supports a different variant of SPIR-V than OpenCL, with the result that some OpenCL C code can't be compiled to work with Vulkan. [1] But it does seem like a combination of lifting Vulkan compute restrictions and building compute-oriented APIs on top of it could be a better path forward. Especially since this new version basically seems to be giving up an getting vendors to support the features that would make OpenCL competitive with CUDA. [1] https://github.com/google/clspv/blob/master/docs/OpenCLCOnVulkan.md#opencl-c-restrictions https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu...
- fluffything 7y ago>So today Khronos is doing something for which I’m not sure there’s any parallel for in the computing industry – and certainly, there’s never been anything like it in the GPU computing ecosystem: the framework is taking a large step backwards. Looking to reset the ecosystem, The people who picked up CUDA can now easily compile it to target NVIDA and AMD GPUs, as well as x86-64 CPUs, using a pletora of compilers (nvcc, hip's framework, PGI compiler for CUDA->x86, Intel's CUDA compiler, ...). Each upgrade to the CUDA platform has been backward compatible, and improved performance by quite a bit. Those who went for OpenCL lost Apple's platform support, have so-so AMD and Intel CPU support, and not so great AMD and NVIDIA GPU support, and now are getting an "ecosystem reset". I find this quite ironic TBH. The main advantage of OpenCL over CUDA on paper was supposed to be the vendor portability, but CUDA is delivering better on that "feature" than OpenCL. And now they land an ecosystem reset. I hope that people can easily migrate their OpenCL 2.x code to OpenCL 3.0. If doing that requires a rewrite, they might as well rewrite their code in CUDA..
- skohan 7y ago> CUDA can now easily compile it to target NVIDA and AMD GPUs, as well as x86-64 CPUs Are these solutions "legal"? I.e. is there a risk NVIDIA can crack down on tools like this from an IP standpoint if they want to at some point in the future?
- fluffything 7y agoIANAL, but: - NVIDIA themselves ship multiple CUDA to multi-core x86-64 compilers for different programming languages CUDA C/C++/Fortran - AMD has been shiping hip for a while, advertising it as production ready, without any lawsuits (AFAIK). hip is also being used in production. - LLVM and clang have had open-source CUDA (and PTX) support for years, and nvidia have not enforced any kind of patents there.
- pjmlp 7y agoThat clang/LLVM support was contributed by NVidia.
- falldrown 7y agoI hope someday they add OpenCL <-> CUDA direct interop (not through OpenGL/DirectX interop API)
- Jonnax 7y agoSo if someone wanted to get into GPU computer what's the best way? Is it CUDA? openCL1.2? Vulkan has some compute stuff, would that be good enough?
- pjmlp 7y agoCUDA definitely. NVidia acknowledged early on that you wouldn't necessarly want to use C on the GPU, and moved CUDA into multi-language support. So while CUDA C++ is the leading language, you can make use of Fortran, Julia, Haskell, .NET, Java, Python as well. You also have very nice graphical tooling for GPGPU debugging, where you can debug your shaders just like any other application. You can go through the GTC 2020 videos, https://www.nvidia.com/en-us/gtc/session-catalog/ https://www.nvidia.com/en-us/gtc/session-catalog/
- raphlinus 7y agoMy personal take on this is that OpenCL is not the way forward, that deployment is going to be on Vulkan and likely WebGPU. But there is an enormous gap in the ecosystem, as Vulkan is very low-level and GLSL is a primitive language for writing compute kernels (though it can be done in theory). I think the OpenCL people get that, and have listed clvk and clspv on their roadmap. That gives considerably better options for actually running compute workloads than crossing one's fingers and hoping that the GPU vendors will implement the spec out of a sense of pity for the spec writers. Another similar project I learned about recently is vuda[1]. Another project to watch closely is JAX/MLIR, which promises to run Tensorflow workloads directly on Vulkan. In that ecosystem, it's not clear at all what value an OpenCL layer would add. I have a blog post in draft about very fast prefix sum running on Vulkan, thanks to a comment from fluffything in response to my GPU talk (could you let me know how you would like to be attributed)? I finally got it to within 10% of memcpy bandwidth over the weekend, so I'm going to declare victory and write it up. [1]: https://github.com/jgbit/vuda https://github.com/jgbit/vuda
- Rochus 7y agoIf a vendor was happy with OpenCL 1.2 but wanted a couple of extra 2.1 features, for example, then to be compliant with the specification they’d need to implement the entire 2.1 core specification Right; from that point of view OpenCL 3.0 is a good move; also IEEE should consider such a strategy with SystemVerilog.