12 ms·

Blender 3.0 takes support for AMD GPUs to the next level

317 points by WithinReason 5y ago

ur-whale 5y ago
> 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.
- psalz 5y ago
  Have you heard of SYCL[1]? :) [1]: https://www.khronos.org/sycl/ https://www.khronos.org/sycl/
- Const-me 5y ago
  In my experience, on Windows, DirectCompute shaders work OK on AMD too. For optimal performance they require optimizations for specific GPUs, though.
- chmod775 5y ago
  > Luckily, AMD has an open-source solution for developers just for that. HIP (Heterogeneous-computing Interface for Portability) is a C++ runtime API and kernel language that allows developers to create portable applications for AMD and NVIDIA® GPUs from a single source code. This allows the Blender Cycles developers to write one set of rendering kernels and run them across multiple devices. The other advantage is that the tools with HIP allow easy migration from existing CUDA® code to something more generic.
  - ur-whale 5y ago
    Yeah, I've read that. But this is not an open standard, it's just a hack, and it is under the control of a vendor. Worse, it is nothing but a thin layer above an even more proprietary layer.
    - chmod775 5y ago
      > But this is not an open standard, it's just a hack, and it is under the control of a vendor. It's under a permissive license (MIT). What makes you say it is "just a hack"? What makes it a hack? > Worse, it is nothing but a thin layer above an even more proprietary layer. The same is true for OpenCL (layer above a proprietary layer) and pretty much any API interfacing with proprietary hardware/drivers. Also it's not even proprietary software in the first place, even if you're trying to make it sound that way.
- floatboth 5y ago
  Vulkan! Compute! Shaders! I hate compute-specific APIs so much. Use Vulkan!
  - gspr 5y ago
    Could you provide some pointers to where someone who's moderately familar with OpenCL should start looking to learn to do compute with Vulkan? I find the documentation quite fractured.
    - floatboth 5y ago
      Don't try to use it directly, you need a higher level library. https://github.com/KomputeProject/kompute https://github.com/KomputeProject/kompute seems like what's taking off. There are also smaller ones like https://github.com/Glavnokoman/vuh https://github.com/Glavnokoman/vuh etc.
      - gspr 5y ago
        Does this mean that OpenCL is being phased out without any serious Vulkan-based replacements being actively worked on?
    - ur-whale 5y ago
      > I find the documentation quite fractured. This has been my experience as well: the few Vulkan Hello, World I've seen all have a mile and half boilerplate code before you can open a window and draw an effing pixel in it. Also, from an admittedly quick glance at Vulkan ... I haven't really seen specs for a full-fledged CUDA / OpenCL modern replacement. Did I miss something?
      - gspr 5y ago
        It's even worse if you don't wanna draw a pixel, but rather want the compute world's equivalent of hello world (i.e. inner product)!
pram 5y ago
What does this mean for ProRender? AMDs Blender strategy is kinda confusing.
- bsavery 5y ago
  Hi there. I help there. ProRender is still very important as it has hardware accelerated raytracing while Cycles does not yet on AMD. Furthermore we're focusing our efforts on ProRender going forward through USD. https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA... Adding USD workflows to blender and other apps while using ProRender for the rendering solution in USD.
- deleted 5y ago
  [deleted]
volta83 5y ago
NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs. Instead, Intel and AMD strategy is pushing applications to "rewrite CUDA with HIP/OneAPI", which are not real standards and are no more portable than CUDA. The people claiming that they are "open", probably also think that OpenACC is an open standard, even though it mostly only runs on NVIDIA GPUs. If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs. You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes. It doesn't get any more portable than that. I don't understand how there are so many people in these threads that apparently care about portability happy about AMD and Intel rewriting open source applications in their proprietary vendor-specific technologies, instead of angry about them pushing their proprietary technologies, instead of implementing GPU support for ISO standard languages, just like NVIDIA does.
- toolz 5y ago
  just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?
  - volta83 5y ago
    Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards. Are you implying that they did a bad job and added the wrong GPU support to ISO C++? Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs? Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.
  - jjoonathan 5y ago
lvl100 5y ago
AMD software support is pretty bad for a company of its size. They’re trying to do the minimum. It’s almost as if they don’t want to compete with Nvidia due to collusion.
boyadjian 5y ago
Wow, being an AMD fan, I’ve been waiting for this for a long time. Impatient to try that with my RX 5700
muizelaar 5y ago
This seems to be the change that adds support for HIP: https://developer.blender.org/rB044a77352f8a8a0e1f60190369d69ef26587b65f https://developer.blender.org/rB044a77352f8a8a0e1f60190369d6...
de6u99er 5y ago
Looks like AMD's open source strategy is starting to pay off.
- smoldesu 5y ago
  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.
  - esistgut 5y ago
    OptiX is not an Intel technology, both CUDA and OptiX rendering backends for Blender's Cycles are powered by Nvidia.
    - dagw 5y ago
      OptiX is not an Intel technology Probably meant Embree
    - cturtle 5y ago
      They probably meant the Intel denoiser bundled with Blender.
  - Hemospectrum 5y ago
    According to other posts, this won’t support Vega graphics; RDNA1 is the absolute minimum, with RDNA2 being the oldest architecture officially supported. Guess we’ll have to wait for new APUs to see how this fares.
- blihp 5y ago
  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.
my123 5y ago
Note that this is only supported on RDNA2 onwards. It is _enabled_ on 1st gen RDNA, but with no "official support" from AMD. (as such, no SLAs or any guarantees really) On prior generations, it's not enabled at all. (Vega, Polaris)
esistgut 5y ago
Maybe ROCm support for Navi hardware is finally going to be released.
jjoonathan 5y ago
Glad 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 time is different. I'm cautiously optimistic... but I'll let someone else be the guinea pig.
- moffkalast 5y ago
  This is mostly why I've stopped buying anything but Nvidia GPUs years ago, in 99% of software people just support CUDA and call it a day it seems.
- philovivero 5y ago
  I wish I could be that guinea pig, but looks like this is a Windows-only thing, and I'm on a Mac.
  - tomovo 5y ago
    Apple is contributing Metal support so there’s another chance.
    - techdragon 5y ago
      Only because the move to their own customised ARM based unified memory architecture means that if they don’t want to completely hemorrhage the remaining loyal customers in the pro market paying for their hardware they have to support at least basic hardware acceleration in these apps. So don’t expect support on anything but the latest hardware. Like their new Metal based Machine learning library junk. Oh whats that you have an Intel Mac with a beefy external GPU supported by Metal… too bad this is M1 only! Doesn’t matter that we supported this in the beta, we’re throwing out everything Intel related because the future is ARM and we no longer care about anything outside our garden. I say all of this grumpily, as a progressively less and less happy Apple customer. Unless a glorious future of high performance x86 emulation of Virtual machines happens I’m forced to get cheaper hardware and buy a second laptop now in order to support GPU heavy windows software (Linux at least looks set to get some measure of support so hopefully it’s not all dire, but it’s still a massive down side for me in the otherwise amazing looking ARM hardware)
shmerl 5y ago
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.
- my123 5y ago
  > 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.
  - raphlinus 5y ago
    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/man/html/VK_KHR_variable_pointers.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... [2]: https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/vulkan-buffer-device-address https://community.arm.com/arm-community-blogs/b/graphics-gam...
mastax 5y ago
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.
- AnthonyMouse 5y ago
  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.
  - WithinReason 5y ago
    Currently Vulkan Compute seems to be the most general compute platform.
  - deleted 5y ago
    [deleted]
  - xvilka 5y ago
    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).
    - AnthonyMouse 5y ago
      AMD and Intel benefit from having the same open source interface to their GPUs even if Nvidia doesn't use it, because it doubles the amount of target hardware for developers. Also remember that AMD and Intel both make discrete GPUs and iGPUs but AMD has much more share in discrete GPUs and Intel has much more share in iGPUs, so this helps them both. And then if either of them managed to hit one out of the park on the hardware side it would benefit both. A really interesting possibility there is to put a strong GPU in a HEDT CPU socket with a lot of memory channels to feed it, because then it shares a memory controller with the CPU and doesn't have to copy over PCIe. That could drive demand, and Nvidia can't do that on a PC without an x86 license but AMD and Intel both can.
EFruit 5y ago
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?
- my123 5y ago
  > 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.
  - slavik81 5y ago
    All future plans are subject to change, but official Navi21 support is expected in ROCm 5.0. It's been shipping unofficially since ROCm 4.2. Official Navi support (5000-series cards), however, is expected in a later release. In current releases, I think the only ROCm library shipping unofficial support is rocBLAS. (I work for AMD on ROCm. All opinions are my own.)
Ono-Sendai 5y ago
How lame, it would have been much nicer to just keep OpenCL functioning well and supported.
- dry_soup 5y ago
  I don't think that was an option. Kernel size limitations prevented Blender from ever supporting OpenCL well. Not to mention Apple dropping official support for it years ago.
sroussey 5y ago
Would be nice to see Apple add M1 support
- doctoboggan 5y ago
  It's coming. Apple joined the blender developement fund and is contributing code to add Metal support to cycles https://developer.blender.org/T92212 https://developer.blender.org/T92212
- lattalayta 5y ago
  That is targeted for Blender 3.1. https://80.lv/articles/blender-3-1-to-add-native-metal-support-in-cycles/ https://80.lv/articles/blender-3-1-to-add-native-metal-suppo...
ldehaan 5y ago
When amd can compete with Nvidia in this space they'll both be the same price. Just buy nvidia.
- mupuff1234 5y ago
  That's not what happened when AMD was competitive in the CPU market vs Intel. If AMD will succeeds, at the very least there will be a long period where they will undercut prices in order to gain market share.
- AnthonyMouse 5y ago
  They might both be the same price, but the price will be lower, because that's how competition works. Which only happens if you support the underdog.
tdrdt 5y ago
Reaults of the Blender benchmark can be found here: https://opendata.blender.org/ https://opendata.blender.org/ Let's see if AMD takes over the GPU top list.
PostThisTooFast 5y ago
Most open-source graphics software is crippled by dogshit UI. So far Blender is not. I'm impressed.
theHIDninja 5y ago
I cannot understand Blender's inanely arcane interface Every tutorial out there seems to be for a drastically different version where half the shit no longer works in the current one without delving into more and more hidden menus Every feature is its own labyrinth of menus, every model downloaded seems to be customized to a unique version with nothing similar to another It is massively disheartening to try to comprehend video tutorials when they're pressing keyboard shortcuts at 20k wpm without explaining them and scouring over every detail trying to understand what they're doing turning an hour long tutorial into a day of confusion I made a shitty donut and don't even know how I did, that's it
- hrnnnnnn 5y ago
  It's a powerful tool and it takes time and effort to learn. I was in the same boat as you when I started, but after ~3 years of using Blender more or less daily I find the UI very intuitive and powerful. One of the nice things about having a very active community is that there's always new tutorials being made, often at the beginner level, on the very latest versions.
  - theHIDninja 5y ago
    Not a single thing about it is intuitive if its UI changes every month.
    - bavell 5y ago
      Sounds like blender might not be for you. Personally I'm super happy with the new UI they revamped a year or so ago in 2.8 (which has barely changed since then). Plus there are tons of great YT videos at all skill levels for inspiration and help. Geometry nodes has been incredible for procedural modeling and I love the direction they're going with it!
    - hrnnnnnn 5y ago
      They constantly make small changes to the UI to improve it. These are good-faith changes aimed at making things clearer, easier to use, and more consistent overall. Since I use blender a lot I can absorb these changes easily. If you're not using it very often it might be harder. However, I'd contest the idea that the "UI changes every month" since there are usually only two or three releases a year.

317 points by WithinReason 5y ago

> 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.

psalz 5y ago
Have you heard of SYCL[1]? :) [1]: https://www.khronos.org/sycl/ https://www.khronos.org/sycl/
Const-me 5y ago
In my experience, on Windows, DirectCompute shaders work OK on AMD too. For optimal performance they require optimizations for specific GPUs, though.
chmod775 5y ago
> Luckily, AMD has an open-source solution for developers just for that. HIP (Heterogeneous-computing Interface for Portability) is a C++ runtime API and kernel language that allows developers to create portable applications for AMD and NVIDIA® GPUs from a single source code. This allows the Blender Cycles developers to write one set of rendering kernels and run them across multiple devices. The other advantage is that the tools with HIP allow easy migration from existing CUDA® code to something more generic.
- ur-whale 5y ago
  Yeah, I've read that. But this is not an open standard, it's just a hack, and it is under the control of a vendor. Worse, it is nothing but a thin layer above an even more proprietary layer.
  - chmod775 5y ago
    > But this is not an open standard, it's just a hack, and it is under the control of a vendor. It's under a permissive license (MIT). What makes you say it is "just a hack"? What makes it a hack? > Worse, it is nothing but a thin layer above an even more proprietary layer. The same is true for OpenCL (layer above a proprietary layer) and pretty much any API interfacing with proprietary hardware/drivers. Also it's not even proprietary software in the first place, even if you're trying to make it sound that way.
floatboth 5y ago
Vulkan! Compute! Shaders! I hate compute-specific APIs so much. Use Vulkan!
- gspr 5y ago
  Could you provide some pointers to where someone who's moderately familar with OpenCL should start looking to learn to do compute with Vulkan? I find the documentation quite fractured.
  - floatboth 5y ago
    Don't try to use it directly, you need a higher level library. https://github.com/KomputeProject/kompute https://github.com/KomputeProject/kompute seems like what's taking off. There are also smaller ones like https://github.com/Glavnokoman/vuh https://github.com/Glavnokoman/vuh etc.
    - gspr 5y ago
      Does this mean that OpenCL is being phased out without any serious Vulkan-based replacements being actively worked on?
  - ur-whale 5y ago
    > I find the documentation quite fractured. This has been my experience as well: the few Vulkan Hello, World I've seen all have a mile and half boilerplate code before you can open a window and draw an effing pixel in it. Also, from an admittedly quick glance at Vulkan ... I haven't really seen specs for a full-fledged CUDA / OpenCL modern replacement. Did I miss something?
    - gspr 5y ago
      It's even worse if you don't wanna draw a pixel, but rather want the compute world's equivalent of hello world (i.e. inner product)!

pram 5y ago

What does this mean for ProRender? AMDs Blender strategy is kinda confusing.

bsavery 5y ago
Hi there. I help there. ProRender is still very important as it has hardware accelerated raytracing while Cycles does not yet on AMD. Furthermore we're focusing our efforts on ProRender going forward through USD. https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA... Adding USD workflows to blender and other apps while using ProRender for the rendering solution in USD.
deleted 5y ago
[deleted]

volta83 5y ago

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs. Instead, Intel and AMD strategy is pushing applications to "rewrite CUDA with HIP/OneAPI", which are not real standards and are no more portable than CUDA. The people claiming that they are "open", probably also think that OpenACC is an open standard, even though it mostly only runs on NVIDIA GPUs. If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs. You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes. It doesn't get any more portable than that. I don't understand how there are so many people in these threads that apparently care about portability happy about AMD and Intel rewriting open source applications in their proprietary vendor-specific technologies, instead of angry about them pushing their proprietary technologies, instead of implementing GPU support for ISO standard languages, just like NVIDIA does.

toolz 5y ago
just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?
- volta83 5y ago
  Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards. Are you implying that they did a bad job and added the wrong GPU support to ISO C++? Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs? Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.
- jjoonathan 5y ago

lvl100 5y ago

AMD software support is pretty bad for a company of its size. They’re trying to do the minimum. It’s almost as if they don’t want to compete with Nvidia due to collusion.

boyadjian 5y ago

Wow, being an AMD fan, I’ve been waiting for this for a long time. Impatient to try that with my RX 5700

muizelaar 5y ago

This seems to be the change that adds support for HIP: https://developer.blender.org/rB044a77352f8a8a0e1f60190369d69ef26587b65f https://developer.blender.org/rB044a77352f8a8a0e1f60190369d6...

de6u99er 5y ago

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

smoldesu 5y ago
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.
- esistgut 5y ago
  OptiX is not an Intel technology, both CUDA and OptiX rendering backends for Blender's Cycles are powered by Nvidia.
  - dagw 5y ago
    OptiX is not an Intel technology Probably meant Embree
  - cturtle 5y ago
    They probably meant the Intel denoiser bundled with Blender.
- Hemospectrum 5y ago
  According to other posts, this won’t support Vega graphics; RDNA1 is the absolute minimum, with RDNA2 being the oldest architecture officially supported. Guess we’ll have to wait for new APUs to see how this fares.
blihp 5y ago
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.

my123 5y ago

Note that this is only supported on RDNA2 onwards. It is _enabled_ on 1st gen RDNA, but with no "official support" from AMD. (as such, no SLAs or any guarantees really) On prior generations, it's not enabled at all. (Vega, Polaris)

esistgut 5y ago

Maybe ROCm support for Navi hardware is finally going to be released.

jjoonathan 5y ago

Glad 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 time is different. I'm cautiously optimistic... but I'll let someone else be the guinea pig.

moffkalast 5y ago
This is mostly why I've stopped buying anything but Nvidia GPUs years ago, in 99% of software people just support CUDA and call it a day it seems.
philovivero 5y ago
I wish I could be that guinea pig, but looks like this is a Windows-only thing, and I'm on a Mac.
- tomovo 5y ago
  Apple is contributing Metal support so there’s another chance.
  - techdragon 5y ago
    Only because the move to their own customised ARM based unified memory architecture means that if they don’t want to completely hemorrhage the remaining loyal customers in the pro market paying for their hardware they have to support at least basic hardware acceleration in these apps. So don’t expect support on anything but the latest hardware. Like their new Metal based Machine learning library junk. Oh whats that you have an Intel Mac with a beefy external GPU supported by Metal… too bad this is M1 only! Doesn’t matter that we supported this in the beta, we’re throwing out everything Intel related because the future is ARM and we no longer care about anything outside our garden. I say all of this grumpily, as a progressively less and less happy Apple customer. Unless a glorious future of high performance x86 emulation of Virtual machines happens I’m forced to get cheaper hardware and buy a second laptop now in order to support GPU heavy windows software (Linux at least looks set to get some measure of support so hopefully it’s not all dire, but it’s still a massive down side for me in the otherwise amazing looking ARM hardware)

shmerl 5y ago

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.

my123 5y ago
> 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.
- raphlinus 5y ago
  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/man/html/VK_KHR_variable_pointers.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... [2]: https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/vulkan-buffer-device-address https://community.arm.com/arm-community-blogs/b/graphics-gam...

mastax 5y ago

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.

AnthonyMouse 5y ago
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.
- WithinReason 5y ago
  Currently Vulkan Compute seems to be the most general compute platform.
- deleted 5y ago
  [deleted]
- xvilka 5y ago
  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).
  - AnthonyMouse 5y ago
    AMD and Intel benefit from having the same open source interface to their GPUs even if Nvidia doesn't use it, because it doubles the amount of target hardware for developers. Also remember that AMD and Intel both make discrete GPUs and iGPUs but AMD has much more share in discrete GPUs and Intel has much more share in iGPUs, so this helps them both. And then if either of them managed to hit one out of the park on the hardware side it would benefit both. A really interesting possibility there is to put a strong GPU in a HEDT CPU socket with a lot of memory channels to feed it, because then it shares a memory controller with the CPU and doesn't have to copy over PCIe. That could drive demand, and Nvidia can't do that on a PC without an x86 license but AMD and Intel both can.

EFruit 5y ago

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?

my123 5y ago
> 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.
- slavik81 5y ago
  All future plans are subject to change, but official Navi21 support is expected in ROCm 5.0. It's been shipping unofficially since ROCm 4.2. Official Navi support (5000-series cards), however, is expected in a later release. In current releases, I think the only ROCm library shipping unofficial support is rocBLAS. (I work for AMD on ROCm. All opinions are my own.)

Ono-Sendai 5y ago

How lame, it would have been much nicer to just keep OpenCL functioning well and supported.

dry_soup 5y ago
I don't think that was an option. Kernel size limitations prevented Blender from ever supporting OpenCL well. Not to mention Apple dropping official support for it years ago.

sroussey 5y ago

Would be nice to see Apple add M1 support

doctoboggan 5y ago
It's coming. Apple joined the blender developement fund and is contributing code to add Metal support to cycles https://developer.blender.org/T92212 https://developer.blender.org/T92212
lattalayta 5y ago
That is targeted for Blender 3.1. https://80.lv/articles/blender-3-1-to-add-native-metal-support-in-cycles/ https://80.lv/articles/blender-3-1-to-add-native-metal-suppo...

ldehaan 5y ago

When amd can compete with Nvidia in this space they'll both be the same price. Just buy nvidia.

mupuff1234 5y ago
That's not what happened when AMD was competitive in the CPU market vs Intel. If AMD will succeeds, at the very least there will be a long period where they will undercut prices in order to gain market share.
AnthonyMouse 5y ago
They might both be the same price, but the price will be lower, because that's how competition works. Which only happens if you support the underdog.

tdrdt 5y ago

Reaults of the Blender benchmark can be found here: https://opendata.blender.org/ https://opendata.blender.org/ Let's see if AMD takes over the GPU top list.

PostThisTooFast 5y ago

Most open-source graphics software is crippled by dogshit UI. So far Blender is not. I'm impressed.

theHIDninja 5y ago

I cannot understand Blender's inanely arcane interface Every tutorial out there seems to be for a drastically different version where half the shit no longer works in the current one without delving into more and more hidden menus Every feature is its own labyrinth of menus, every model downloaded seems to be customized to a unique version with nothing similar to another It is massively disheartening to try to comprehend video tutorials when they're pressing keyboard shortcuts at 20k wpm without explaining them and scouring over every detail trying to understand what they're doing turning an hour long tutorial into a day of confusion I made a shitty donut and don't even know how I did, that's it

hrnnnnnn 5y ago
It's a powerful tool and it takes time and effort to learn. I was in the same boat as you when I started, but after ~3 years of using Blender more or less daily I find the UI very intuitive and powerful. One of the nice things about having a very active community is that there's always new tutorials being made, often at the beginner level, on the very latest versions.
- theHIDninja 5y ago
  Not a single thing about it is intuitive if its UI changes every month.
  - bavell 5y ago
    Sounds like blender might not be for you. Personally I'm super happy with the new UI they revamped a year or so ago in 2.8 (which has barely changed since then). Plus there are tons of great YT videos at all skill levels for inspiration and help. Geometry nodes has been incredible for procedural modeling and I love the direction they're going with it!
  - hrnnnnnn 5y ago
    They constantly make small changes to the UI to improve it. These are good-faith changes aimed at making things clearer, easier to use, and more consistent overall. Since I use blender a lot I can absorb these changes easily. If you're not using it very often it might be harder. However, I'd contest the idea that the "UI changes every month" since there are usually only two or three releases a year.