Blender 3.0 takes support for AMD GPUs to the next level
11–20 of 117 posts
Re: Blender 3.0 takes support for AMD GPUs to the next level
#121. 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?
Re: Blender 3.0 takes support for AMD GPUs to the next level
#13Looks 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.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#14Why 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.
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
#15Two 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?
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
#16Earlier 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.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#17Looks like AMD's open source strategy is starting to pay off.
Re: Blender 3.0 takes support for AMD GPUs to the next level
#18Re: Blender 3.0 takes support for AMD GPUs to the next level
#19Why 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…
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...