Live data from Hacker News

Blender 3.0 takes support for AMD GPUs to the next level

gpuopen.com

11–20 of 117 posts

Re: Blender 3.0 takes support for AMD GPUs to the next level

#11
It'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 be a shame for that advantage to be wasted by a lack of software support.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#13
post #4
post #3

Looks like AMD's open source strategy is starting to pay off.

I wouldn't go that far. Nvidia and even Intel have had hardware-accelerated features in Blender (RTX-acceleration and Optix, respectively), so this is more about getting them back on the same level. I do really like AMD GPUs though, I'd be interested to see how this performs on their APUs with the Vega graphics.

OptiX is not an Intel technology, both CUDA and OptiX rendering backends for Blender's Cycles are powered by Nvidia.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#14
post #10

Why HIP and not for example Vulkan? UPDATE: Looks like this more about adapting existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too.

As described by Brecht Van Lommel (Blender and Cycles developer):

Vulkan has limitations in how you can write kernels, in practice you can’t currently use pointers for example. But also, GPU vendors will recommend certain platforms for writing production renderers, provide support around that, and various renderers will use it. Choosing a different platform means you will hit more bugs and limitations, have slower or no access to certain features, are not likely to see library support like OSL, etc.

Our strategy for Cycles X is to rely on the GPU vendors to support us and provide APIs that meet our requirements. We want to support as many GPUs as possible, but not at any cost.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#15
post #12

Two major questions come to mind: 1. What will the impact be for ROCm's Navi support on Linux? 2. Does this mean they're getting more confident at handling simultaneous display AND compute with ROCm?

> 1. What will the impact be for ROCm's Navi support on Linux?

You will see that supported officially in ROCm 5.0, the next ROCm release. Note that ROCm 5.0 drops support for first generation Vega GPUs. (Radeon Instinct MI25)

The only consumer card to have shipped with second gen Vega is the Radeon VII.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#16
post #4

Earlier quoted context omitted.

I wouldn't go that far. Nvidia and even Intel have had hardware-accelerated features in Blender (RTX-acceleration and Optix, respectively), so this is more about getting them back on the same level. I do really like AMD GPUs though, I'd be interested to see how this performs on their APUs with the Vega graphics.

OptiX is not an Intel technology, both CUDA and OptiX rendering backends for Blender's Cycles are powered by Nvidia.

They probably meant the Intel denoiser bundled with Blender.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#17
post #3

Looks like AMD's open source strategy is starting to pay off.

Not really on the compute side yet. This is their 2nd attempt at supporting Blender as the first (an OpenCL renderer for Blender) was deemed unmaintainable and deprecated shortly after it was released. All indications are AMD is doing much better on the video driver side (which is where the good news is), but on the compute side they appear to have a long way to go still.

Re: Blender 3.0 takes support for AMD GPUs to the next level

#19
post #14
post #10

Why HIP and not for example Vulkan? UPDATE: Looks like this more about adapting existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose. It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too. As described by Brecht Van Lommel (Blender and Cycles developer): Vulkan has limitatio…

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 scope came to me for advice, I would absolutely 100% recommend they base their stuff on Vulkan. It's getting very good quite quickly; there's basically nothing holding you back any more if you're willing to use the latest extensions. There is a tendency in open source to move more slowly though, and I understand that.

I agree with you that GLSL/HLSL is a bad programming language, but you can still get your work done in it. I'm personally excited about rust-gpu, but that is not ready yet.

[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions...

[2]: https://community.arm.com/arm-community-blogs/b/graphics-gam...

Post reply on HN