Apple 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.
So 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.
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.
Over 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.
~5 years ago I burned myself badly by choosing OpenCL and AMD cards as a compute platform. I expected the OpenCL ecosystem to be at rough parity with the CUDA ecosystem in terms of features and performance. That couldn't have been further from the case. I wound up selling my cards, eating the spread + shipping + 10% ebay fees, and switching teams.
Just bite the bullet and pay the green tax. It's cheaper than your health and sanity.
It 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.
The 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.
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.
It depends on what you are trying to achieve. If you are trying to teach gamedev, then I agree it is a pain. However, if you teach a general graphics course in a CS curriculum, then the slow, spec-like approach is way better.
Regardless I never liked the NeHe tutorials for some reason. I did them when fixed pipeline was a thing and they bore me a lot, yeah... but when I learnt modern GL properly it was way better. Seeing a cube rotate is irrelevant to motivation as long as you understand what you are doing, in my experience.
I think I mostly just want to assuage my embarrassment about being a computer programmer with no idea how to use most of the computing power in modern computers.
Edit: And ideally I'd like to be able to learn on my "Intel Integrated Graphics" laptop, although I don't care about performance there.
Maybe I should be looking into something that can target SPIR-V via LLVM, or something? Don't know what good options currently exist for for that. I'm generally a bit lost, if that's not already obvious.
> ideally I'd like to be able to learn on my "Intel Integrated Graphics" laptop
NO.
Rent a cloud server or buy an old computer with a discrete GPU. Don't even try winging it. This is not x86 land where everything works everywhere. Not even close. NVIDIA/CUDA is what everyone does, AMD/OpenCL is like shooting yourself in the foot, and Intel Integrated / OpenCL is like shooting yourself in the head.
Yes, really. Last time I encountered Intel Integrated, I spent an entire weekend trying to port a relatively trivial shader. It would compile and run, but the output was always very wrong. Needless to say, the tooling was no help, and remember this is GPU land where you don't have printf, but I eventually discovered the problem: 8 bit floats. Yes, 8 bit floats are a thing in Intel Integrated land. No, it didn't give me any warning it was using them. "You asked for a float, you got a float, what's the problem?" I imagine an intel engineer saying. Because I'm a stubborn SOB I didn't learn my lesson there and I soldiered on -- next bug was a silent pageout issue.
Does this sound like fun? If so, go for it. If not, buy a discrete GPU. AMD might be OK these days, they've been working on their problems, but once bitten twice shy, so my recommendation is to buy something with an NVIDIA GPU and consider the green tax an investment in your mental health.
> Yes, really. Last time I encountered Intel Integrated, I spent an entire weekend trying to port a relatively trivial shader.
What are you talking about? What API were you using? I use Vulkan to target multiple GPU architectures and I have never had a problem with compatibility or shader behavior, even with very complex multi-pipeline processes.
In general, if your code doesn't throw validation warnings, it will do what you expect on any hardware.
GLSL. Maybe Intel Integrated works better with Vulkan, but 8 bit floats were a hardware choice. The only way to "support" them would be to throw warnings/errors or kick back to software emulation.
I mean if all you want to do is dip your toe in the water with GPGPU programming OpenCL is probably honestly a fine place to start. Specific knowledge of the OpenCL API is probably not the most useful thing in the world, but you will learn a lot about the basic concepts about how the host and the GPU talk to each-other, and how the constraints of GPU programming are different than CPU programming, all of which will carry over to other technologies like CUDA or Vulkan.
You could also get started with a simple Vulkan compute example, but as others have said learning Vulkan is a task unto itself, so if you're just playing around and you're not sure if you really want to invest in learning it for something valuable, it might be more of a time sync than you're interested in.
> I mean if all you want to do is dip your toe in the water with GPGPU programming OpenCL is probably honestly a fine place to start.
I think really that is all I want at this point. But I'm taking the many dire warnings under advisement. Vulkan sounds a bit hardcore for me right now.
While if closed source is a dealbreaker for you, I can understand your conclusion, but otherwise just use CUDA. It is better in simply all the ways that matter, with a simpler API and a lot more resources.
You are honestly better off renting a cheap spot priced GPU instance than trying to do anything on a laptop, doubly so if said laptop GPU is not even supported by CUDA.
Otherwise your whole learning experience is going to be an exercise in frustration with almost zero tangible output.
Mesa 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.
Would 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?
This 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.
I'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?
One 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.
>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..
> 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?
The original version of the NVPTX backend was contributed by nvidia, but iiuc they abandoned it afterwards and I think all the work on it since then has been by Google.
> How do people do GPGPU on AMD today? Because I thought AMD has a huge cloud GPU market share for things like ML
ROCm and HIP [^1] or OpenCL.
OpenCL is the hated solution of GPGPU. It is low level, incomplete and definitively not with a mature ecosystem of tools like Cuda. But it is currently the only one existing if you want your program to run on something else than Nvidia GPU ( Meaning AMD, Intel, phone GPUs or FPGA accelerators).
AMD has a tiny market share in the cloud GPU market. AWS, Google Cloud, and Azure all have compute instances with NVIDIA GPUs, and I don't think any with AMD GPUs (IIRC Azure maybe has windows instances with AMD GPUs for graphics).
It's a gray area and currently being litigated. If Oracle prevails, then NVidia absolutely would be in a position to shut down compatible implementations of CUDA, or dictate the terms under which they might or might not be able to continue to exist.
Using open standards avoids this risk, though some companies are unwilling to work with Khronos, citing (not publicly detailed) legal concerns.
I just want to be able to install a program or library, like Tensorflow, and have it work on my GPU whether it's from Nvidia or AMD without having to first find and install the right compiler.
How do I run a Python program that imports Tensorflow on my AMD GPU today?
That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.
If you are installing TF from source, then it becomes your job. TF docs should help you here, and TF's build-system should be able to guide you through what you need to install.
> That's something you need to ask to your package manager. Making sure that all dependencies of a package (e.g. drivers, compilers, etc.) are installed is the package manager's job.
No that's bullshit and it shows you never have done it.
Tensorflow is CUDA only and does not run over AMD GPU. Because CUDA is proprietary and has a monopoly on GPGPU for now.
It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP. This naturally makes it behind upstream, buggy and partially updated [^1]
CUDA is not portable and will never be.
The sad truth is that, due to CUDA, a big majority of GPGPU programs are now vendor lock-in on Nvidia hardware. That is unacceptable, but it is like that.
> It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP.
That's because HIP requires changes to the program source code, but AMD has managed to upstream those patches to other projects. If they haven't done that for Tensorflow, that's kind of their problem.
Clang can compile CUDA code, and it has an AMDGpu backend. AMD could compile that CUDA code to SPIRV if they wanted. Intel and PGI do compile CUDA to x86-64 using LLVM without problems.
ROCm is only officially supported on AMD Instinct GPUs. For others, it’s a best effort thing only:
“ AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.”
It is like Khronos keeps missing the point why developers jump into more productive eco-systems.
Lets see how they manage Vulkan, which keeps getting extensions that NVidia and AMD first develop in DirectX anyway, like Raytracing and mesh shaders.
Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V, because plenty of game developers weren't willing to write GLSL, or to port their shaders.
For those that don't know shading languages HLSL is closer to C++ in language features, also similar to what PS4 uses, while GLSL is pretty much still stuck in being a C derived shading language.
>It is like Khronos keeps missing the point why developers jump into more productive eco-systems.
They have a history of doing it for the past 20 years. So when the article said "Taking some hard earned (and hard learned) lessons to heart,". I laughed.
I am not even sure they learned anything. And it is the same reason I dont understand why everyone is chanting Vulkan. It is the same /similar story with OpenGL vs 3DFx Glide.
Vulkan is a breath of fresh air compared to OpenGL. The documentation is great, it runs everywhere, and if it passes validation I get consistent results on whatever hardware I want to run it on.
I'm not sure why I would want to target 4+ proprietary API's instead of one modern, open API which is well-designed and performs great.
Just wait a couple of releases more until the extension registry starts matching the OpenGL one, and one needs to write multiple code paths depending on the targeted GPUs.
Is that not equally true of DX12? How can I execute mesh shaders on hardware which doesn't support them?
This is not a sin of Vulkan, it's just the reality of a fragmented GPU landscape.
At least Vulkan has a sensible, consistent API around extensions, and makes it easy to verify that your hardware has the capabilities you need in order to use a given feature.
DirectX 12 Ultimate is a different thing than DirectX 12. Game developers aren't just going to be able to target Ultimate if they want to capture any users with older than current generation NVIDIA or next gen AMD GPUs.
edit: if I was using Vulkan and only wanted to target DX12 Ultimate-certified hardware I would still be able to use only one code-path. This would basically mean that I am choosing to only support hardware which supports a certain set of extensions
No, the original argument was that DirectX, or any other proprietary API from Apple, Nintendo and Sony, don't need the extension jungle of Vulkan and OpenGL, the former with almost weekly updates.
Which than feds into learning the APIs and not having to deal with multiple execution paths.
In DirectX there is only one way of doing RayTracing, in the Khronos APIs, well it depends. Same applies to lots of other features.
You're comparing apples and oranges. Your argument is that proprietary API's are better than Vulkan because there are less code paths, but if you go that way you need a completely separate code path for each top-level API.
I think you're vastly over-stating the complexity of handling this in Vulkan. For the ray-tracing example, realistically you have one branch for non-ray-tracing, and one more where you check for whatever RT extensions you need and do ray-tracing if you have them available. This is exactly the same complexity you would have with DX12.
DX12 Ultimate is a really poor counterpoint. No serious game developer is going to be content targeting only XBoxSX and PCs build for over $1200 in the last 18 months. Realistically, even if you only target MS platforms, you're probably even going to need a DX11 renderer, and the DX12 API is already quite different on XBox and PC, so that's already 3 code-paths minimum.
> Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V, because plenty of game developers weren't willing to write GLSL, or to port their shaders.
What is your argument here exactly? Isn't it one of the stated benefits of Vulkan, that because of SPIR-V as a shader language, developers can choose whatever high-level language they write to implement shaders in?
If developers can target Vulkan without re-writing their shaders that seems like a sign of strength not a sign of weakness.
GLSL is not part of Vulkan's value proposition and has no bearing on Vulkan's success. The competitive feature which Vulkan offers is it's non-proprietary nature and crosss-platform support. If it can deliver that with the same or better performance as proprietary solutions, and offering developers more choice about which language they want to implement shaders in, this is a clear win for Vulkan.
You'd think Khronos would learn from their (many) past mistakes with OpenGL but apparently they seem to miraculously have found some leftover foot left to shoot. I guess hindsight is 20/20 and all that but it's pretty crazy that they seem to miss the mark so reliably over the years.
I'm not much of a graphics programmer, so take this with a grain of salt, but from talking to people who are, the impression I've gotten is that OpenGL is stuck in this weird middle state where it still has two ways of doing things, a simple and easy, but inefficient way where you specify everything from scratch each frame, and one where you use more persistent state like vertex buffer objects to minimize copying and speed things up, but the latter has a cumbersome bolted-on-top API. By comparison DirectX only supports the latter, but was from the start designed with a nicer API to deal with this persistent state, so engine programmers tend to prefer it. And rumor has it that it was the CAD companies that were preventing a modernization of the OpenGL API to properly compete with the ease-of-use of DirectX. So this wasn't just a fight of open vs proprietary, it was also a fight of design-by-committee vs single coherent architectural vision.
This isn't really accurate; the immediate-mode approach you're talking about was deprecated in OpenGL 3.0 and was never supported in OpenGL ES, and in fact, Direct3D started out with an immediate-mode API just like OpenGL before moving to retained vertex buffers.
As someone who spent quite a bit of time with OpenGL, this criticism never really scanned with me. Yes there were multiple ways to do things, but it was fairly easy to understand what the modern parts of the API were and just use that subset. If you run through any modern OpenGL tutorial it will explain this very concisely, and I never had an issue being unsure which parts of the API to use.
That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.
With regards to HIP, here is a quote from AMD's FAQ:
> Most developers will port their code from CUDA to HIP and then maintain the HIP version. HIP code provides the same performance as native CUDA code, plus the benefits of running on AMD platforms.
E.g. AMD wants developers to develop primarily in HIP. The CUDA->HIP transpilation tools is to help developers make the switch.
So 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.
This 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.
The 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.
My 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.
If 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.
123 comments
[ 4.3 ms ] story [ 199 ms ] threadDo 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,
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
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.
Interested to hear opinions on whether that was a reasonable conclusion, and whether this makes a difference to it.
Just bite the bullet and pay the green tax. It's cheaper than your health and sanity.
Just getting through the Vulkan tutorial is a weekend long affair.
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.
They are fine to get some complex features working specially early on, yes, but not for learning.
Those SDKs allow plenty of wanna be game developers to just be doing rotating cubes in less than a couple of minutes and go from there.
Sit in a room trying to go through NeHe tutorials and watch students motivation slowly fade away.
Regardless I never liked the NeHe tutorials for some reason. I did them when fixed pipeline was a thing and they bore me a lot, yeah... but when I learnt modern GL properly it was way better. Seeing a cube rotate is irrelevant to motivation as long as you understand what you are doing, in my experience.
Edit: And ideally I'd like to be able to learn on my "Intel Integrated Graphics" laptop, although I don't care about performance there.
Maybe I should be looking into something that can target SPIR-V via LLVM, or something? Don't know what good options currently exist for for that. I'm generally a bit lost, if that's not already obvious.
NO.
Rent a cloud server or buy an old computer with a discrete GPU. Don't even try winging it. This is not x86 land where everything works everywhere. Not even close. NVIDIA/CUDA is what everyone does, AMD/OpenCL is like shooting yourself in the foot, and Intel Integrated / OpenCL is like shooting yourself in the head.
Yes, really. Last time I encountered Intel Integrated, I spent an entire weekend trying to port a relatively trivial shader. It would compile and run, but the output was always very wrong. Needless to say, the tooling was no help, and remember this is GPU land where you don't have printf, but I eventually discovered the problem: 8 bit floats. Yes, 8 bit floats are a thing in Intel Integrated land. No, it didn't give me any warning it was using them. "You asked for a float, you got a float, what's the problem?" I imagine an intel engineer saying. Because I'm a stubborn SOB I didn't learn my lesson there and I soldiered on -- next bug was a silent pageout issue.
Does this sound like fun? If so, go for it. If not, buy a discrete GPU. AMD might be OK these days, they've been working on their problems, but once bitten twice shy, so my recommendation is to buy something with an NVIDIA GPU and consider the green tax an investment in your mental health.
What are you talking about? What API were you using? I use Vulkan to target multiple GPU architectures and I have never had a problem with compatibility or shader behavior, even with very complex multi-pipeline processes.
In general, if your code doesn't throw validation warnings, it will do what you expect on any hardware.
You could also get started with a simple Vulkan compute example, but as others have said learning Vulkan is a task unto itself, so if you're just playing around and you're not sure if you really want to invest in learning it for something valuable, it might be more of a time sync than you're interested in.
I think really that is all I want at this point. But I'm taking the many dire warnings under advisement. Vulkan sounds a bit hardcore for me right now.
Otherwise your whole learning experience is going to be an exercise in frustration with almost zero tangible output.
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/OpenCLCOnVu...
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..
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?
- 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.
Hip is not Cuda and even remove most mention if cuda from its API. It just mimic cuda API to try to provide compatibility.
And the result is that almost nobody use it today.
ROCm and HIP [^1] or OpenCL.
OpenCL is the hated solution of GPGPU. It is low level, incomplete and definitively not with a mature ecosystem of tools like Cuda. But it is currently the only one existing if you want your program to run on something else than Nvidia GPU ( Meaning AMD, Intel, phone GPUs or FPGA accelerators).
[^1] https://github.com/ROCmSoftwarePlatform/
According to https://www.techquila.co.in/nvidia-cloud-ai-gpu-share/, AMD is at ~1%.
I'm sure NVIDIA IP includes the CUDA trademark, their own compilers, SDKs and so on... but the language itself ?
Using open standards avoids this risk, though some companies are unwilling to work with Khronos, citing (not publicly detailed) legal concerns.
[1]: https://en.wikipedia.org/wiki/Google_v._Oracle_America
How do I run a Python program that imports Tensorflow on my AMD GPU today?
If you are installing TF from source, then it becomes your job. TF docs should help you here, and TF's build-system should be able to guide you through what you need to install.
No that's bullshit and it shows you never have done it.
Tensorflow is CUDA only and does not run over AMD GPU. Because CUDA is proprietary and has a monopoly on GPGPU for now.
It is such a big deal that AMD had to fork tensorflow and try to make their own version it in order to make it "partially" run over HIP. This naturally makes it behind upstream, buggy and partially updated [^1]
CUDA is not portable and will never be.
The sad truth is that, due to CUDA, a big majority of GPGPU programs are now vendor lock-in on Nvidia hardware. That is unacceptable, but it is like that.
[^1]: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream
That's because HIP requires changes to the program source code, but AMD has managed to upstream those patches to other projects. If they haven't done that for Tensorflow, that's kind of their problem.
Clang can compile CUDA code, and it has an AMDGpu backend. AMD could compile that CUDA code to SPIRV if they wanted. Intel and PGI do compile CUDA to x86-64 using LLVM without problems.
https://rocm-documentation.readthedocs.io/en/latest/Deep_lea...
“ AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.”
https://github.com/RadeonOpenCompute/ROCm/issues/887#issueco...
> "Vega 10" chips, such as on the AMD Radeon RX Vega 64 and Radeon Instinct MI25
https://github.com/RadeonOpenCompute/ROCm
But if you’re using the current consumer product line, it’s hit or miss.
Lets see how they manage Vulkan, which keeps getting extensions that NVidia and AMD first develop in DirectX anyway, like Raytracing and mesh shaders.
Google and Samsung had to adapt Microsoft's HLSL compiler to target SPIR-V, because plenty of game developers weren't willing to write GLSL, or to port their shaders.
For those that don't know shading languages HLSL is closer to C++ in language features, also similar to what PS4 uses, while GLSL is pretty much still stuck in being a C derived shading language.
Hence why Google and Samsung spent about one year doing it for HLSL, and it still isn't 100% compliant with DXIC.
Implementation and standardization should go hand-in-hand, to make sure that you don't standardize something that's unimplementable.
If you can't find companies to implement the standard while it's being developed, then maybe nobody cares?
They have a history of doing it for the past 20 years. So when the article said "Taking some hard earned (and hard learned) lessons to heart,". I laughed.
I am not even sure they learned anything. And it is the same reason I dont understand why everyone is chanting Vulkan. It is the same /similar story with OpenGL vs 3DFx Glide.
Contrary to urban myths Khronos APIs have little uptake on consoles, if they are supported at all.
Even on Switch there is the option of going with NVN or middleware like Unity and Unreal.
According to Unity official numbers, they have about 50% of share across Switch titles.
So no Vulkan at all for Series X? Not even planned? That is sad but expected :(
I'm not sure why I would want to target 4+ proprietary API's instead of one modern, open API which is well-designed and performs great.
This is not a sin of Vulkan, it's just the reality of a fragmented GPU landscape.
At least Vulkan has a sensible, consistent API around extensions, and makes it easy to verify that your hardware has the capabilities you need in order to use a given feature.
edit: if I was using Vulkan and only wanted to target DX12 Ultimate-certified hardware I would still be able to use only one code-path. This would basically mean that I am choosing to only support hardware which supports a certain set of extensions
Which than feds into learning the APIs and not having to deal with multiple execution paths.
In DirectX there is only one way of doing RayTracing, in the Khronos APIs, well it depends. Same applies to lots of other features.
I think you're vastly over-stating the complexity of handling this in Vulkan. For the ray-tracing example, realistically you have one branch for non-ray-tracing, and one more where you check for whatever RT extensions you need and do ray-tracing if you have them available. This is exactly the same complexity you would have with DX12.
DX12 Ultimate is a really poor counterpoint. No serious game developer is going to be content targeting only XBoxSX and PCs build for over $1200 in the last 18 months. Realistically, even if you only target MS platforms, you're probably even going to need a DX11 renderer, and the DX12 API is already quite different on XBox and PC, so that's already 3 code-paths minimum.
What is your argument here exactly? Isn't it one of the stated benefits of Vulkan, that because of SPIR-V as a shader language, developers can choose whatever high-level language they write to implement shaders in?
If developers can target Vulkan without re-writing their shaders that seems like a sign of strength not a sign of weakness.
Also in the age of middleware, Vulkan is only a checkbox away, so unless one is writing game engines, it is quite irrelevant.
For example, OctaneRender gave up on the Vulkan backend and replaced their prototype with Optix 7.
I bet no one on the VFX movie industry will care one second about their change.
edit: just for the record, pjlmp added everything after the 1st line to his comment after I posted this response
Every party in this is a PoS in once sense or another.
1) Are there issues?
RESOLVED: Yes.
https://www.khronos.org/registry/vulkan/specs/1.2-extensions...
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...
That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.
> Most developers will port their code from CUDA to HIP and then maintain the HIP version. HIP code provides the same performance as native CUDA code, plus the benefits of running on AMD platforms.
E.g. AMD wants developers to develop primarily in HIP. The CUDA->HIP transpilation tools is to help developers make the switch.
Because with the reset to OpenCL 1.2-derrived specification good luck with SYCL adoption, let alone anyone caring to write SPIR-V backends.
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.
Also Intel GPUs just suck at everything that isn't doing 2D GUI acceleration anyway.
Can confirm. 8 bit floats. Yes, really.
Not everything is AAA games.
(Unless there are recent issues that I am unaware of, I don't follow why the mix between hardware and API).
Is it CUDA? openCL1.2? Vulkan has some compute stuff, would that be good enough?
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/
Outside of the marketing, 99% of CUDA program are done in 'C++ CUDA'.
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
Right; from that point of view OpenCL 3.0 is a good move; also IEEE should consider such a strategy with SystemVerilog.