> This removed OpenCL™ support for rendering on AMD GPUs for technical and performance reasons.
So, that's it, OpenCL is out the door, no more standardized way to write GPU compute code, I guess.
Blender 3.0 takes support for AMD GPUs to the next level
41–50 of 117 posts
Re: Blender 3.0 takes support for AMD GPUs to the next level
#42Earlier quoted context omitted.
This doesn't sound right to me. Vulkan 1.2 has support for pointers through an extension[1], and that's getting more widely available (certainly a lot more cards than can run ROCm). There's also support coming down the pike for buffer device address[2], which basically lets you use pointers to refer to resources when submitting work to the GPU instead of having to create bindings. If an open source project of this sc…
You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town.
I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possible to develop good tools that run on top of it. That's happening to a large extent in the machine learning space with IREE, much less so here though.
I should also say, I'm not disagreeing with the strategy Blender has chosen, specifically getting vendors to support tuned ports to their hardware. I'm just saying that these specific criticisms of Vulkan (like lacking pointers) aren't really valid.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#43It's good that AMD is providing support for some of their customers since OpenCL is being removed in 3.0. I hope that this is just the start of far greater investment into their software ecosystem. It was understandable that AMD invested less in drivers and support software when they were almost bankrupt but that excuse is drying up. There are rumors that future AMD GPU architectures will be quite good and it would b…
They should really get together with Intel on an open standard, now that Intel is doing real GPUs. They both have a shared interest in people not being stuck on proprietary Nvidia interfaces.
Well ROCm and HIP are "open" and run on AMD and Nvidia GPUs. I'm sure AMD would've been happy for Intel to build on that. But they didn't.
"oneAPI is a cross-industry, open, standards-based unified programming model..." I'm sure they'd be happy for AMD to build on that. But they won't.
I think they'll both push their own APIs as the portable standard, but they can't rely on their competitors to contribute. Intel has much more developer grunt and a much more confident start, though they're a latecomer to GPUs.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#44Glad to hear it. We're going on 10 years since Blender notionally got OpenCL support, I bought an AMD GPU on that basis, found out that the "OpenCL support" was so thoroughly dismal that it was slower than my CPU, sold my AMD card, ate the ebay fees, bought an NVidia card, ate the green tax, and got on with my work. I had to repeat that lesson a few years later with deep learning code before it stuck. Hopefully this…
Is it a 'green tax' when NVIDIA's product is superior in almost every way? There's only two negatives to NVIDIA products right now: poor MacOS support and their linux drivers aren't quite as good as AMD's. Everything compute uses NVIDIA/OptiX. AMD's Windows drivers suck. I had no end of problems with games crashing and micro-stuttering. I used DDU to remove the old drivers, ran Tron, all sorts of troubleshooting step…
> AMD's GPUs use significantly more power in their class.
This says otherwise https://www.tomshardware.com/features/graphics-card-power-co... - it puts RX 6800 at the best performance per watt
Re: Blender 3.0 takes support for AMD GPUs to the next level
#45Earlier quoted context omitted.
They should really get together with Intel on an open standard, now that Intel is doing real GPUs. They both have a shared interest in people not being stuck on proprietary Nvidia interfaces.
Well ROCm and HIP are "open" and run on AMD and Nvidia GPUs. I'm sure AMD would've been happy for Intel to build on that. But they didn't. "oneAPI is a cross-industry, open, standards-based unified programming model..." I'm sure they'd be happy for AMD to build on that. But they won't. I think they'll both push their own APIs as the portable standard, but they can't rely on their competitors to contribute. Intel has…
Are ROCm and HIP considered any good? I've long since given up trying to figure out what ROCm is and what "installing it" means but I suppose it might be time for another attempt. I see PyTorch supports it now.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#46Earlier quoted context omitted.
They should really get together with Intel on an open standard, now that Intel is doing real GPUs. They both have a shared interest in people not being stuck on proprietary Nvidia interfaces.
The only hope for opensource only if NVIDIA as a company ceases to exist - go bankrupt, for example. They are inherently hostile to FOSS and will never change (they didn't change in last decades, why they would in the future).
They may literally be the last holdout among the hardware manufacturers. 15 years ago nearly every vendor was the same. They've all caved over time - can't fight OSS forever.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#47Glad to hear it. We're going on 10 years since Blender notionally got OpenCL support, I bought an AMD GPU on that basis, found out that the "OpenCL support" was so thoroughly dismal that it was slower than my CPU, sold my AMD card, ate the ebay fees, bought an NVidia card, ate the green tax, and got on with my work. I had to repeat that lesson a few years later with deep learning code before it stuck. Hopefully this…
I wish I could be that guinea pig, but looks like this is a Windows-only thing, and I'm on a Mac.
Apple is contributing Metal support so there’s another chance.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#48Reaults of the Blender benchmark can be found here: https://opendata.blender.org/
Let's see if AMD takes over the GPU top list.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#49Earlier quoted context omitted.
The only hope for opensource only if NVIDIA as a company ceases to exist - go bankrupt, for example. They are inherently hostile to FOSS and will never change (they didn't change in last decades, why they would in the future).
They may literally be the last holdout among the hardware manufacturers. 15 years ago nearly every vendor was the same. They've all caved over time - can't fight OSS forever.
Except they all end up going shareware like model where the FOSS alone is useless without the proprietary magic dust.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#50Earlier quoted context omitted.
You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town. I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possib…
If I have learned anything from Khronos APIs is that if Internet was a Khronos standard instead of IETF, we would only have IP as standard, while everyone else had to come up with TCP, UDP, HTTP,... as extensions.
Language support and tooling are never better than the alternatives.