5 ms·

> Support for hardware ray-tracing acceleration has been added for AMD and Intel graphics cards. Added experimental support for AMD hardware ray-tracing acc

> Support for hardware ray-tracing acceleration has been added for AMD and Intel graphics cards. Added experimental support for AMD hardware ray-tracing acceleration, using HIP RT. This improves performance on RX 6000, RX 7000, W6000, and W7000 series GPUs. Known limitations: Windows only, as HIP RT doesn’t support Linux yet. Degenerate triangles may causes crashes or poor performance. Shadows in hair are not rendering accurately. > Windows only, as HIP RT doesn’t support Linux yet NOOOOOO. I guess I'll have to stay with Blender 2.80 for now. Honestly, the situation with hardware acceleration on Linux is pretty sad. I'm a full-time Linux user, and I acquired an AMD GPU specifically because of better Linux support and much better open-source drivers. Blender 3 taking so much time to give AMD Linux users hardware acceleration back makes me sad. I guess it's not misguided though, they got a lot of attention from the industry in recent years, and that's where funding comes from, so naturally they will focus on supporting the major use cases (i.e. Windows and Nvidia) and improving features. Though I do love the new and improved features, UV packing, for instance, was a longtime pet peeve of mine while using Blender compared to other (closed-source) modeling packages.

charcircuit 3y ago
>because of better Linux support In my experience nvidia has better Linux support. Just look at how many projects are using Linux and cuda and don't support AMD.
- doodlesdev 3y ago
  Depends on what you're doing, which GPU you go for, etc. For my use cases switching from NVIDIA to AMD was a great decision. Also, if you're going to stick with open source drivers there is basically no comparison. Just for reference, what setup are you using? (Linux kernel, drivers, GPU, etc.)
- iFire 3y ago
  For example, on my AMD Linux test case, dual monitors and one with VR would be unstable. Nvidia handled it ok.
- colechristensen 3y ago
  AMD has much better open source drivers. nvidia gives you a binary blob... but it works better.
  - wswope 3y ago
    That's out of date, I believe. Nvidia went open source last year, though they did that by moving a lot of code from the drivers over to their firmware (in binary blob form). https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
    - circuit10 3y ago
      That’s only for the kernel part, not the userspace part
    - opencl 3y ago
      Those open source kernel modules are not usable in any practical sense for consumer hardware in their current state. From the repo readme[1], "GeForce and Workstation support is still considered alpha-quality." [1] https://github.com/NVIDIA/open-gpu-kernel-modules https://github.com/NVIDIA/open-gpu-kernel-modules
      - captn3m0 3y ago
        Another limitation was in the GPUs supported - only the latest generation is supported, so no support for common consumer level cards - (1050, 1080 etc).
- bee_rider 3y ago
  It seems like Nvidia’s stuff is a bit more difficult to work with for the community, but the community puts a ton more effort into it.
  - jjoonathan 3y ago
    The GPGPU community is full of a decade+ of bright-eyed bushy-tailed AMD fans who were painfully and traumatically pushed into the NVidia camp after believing AMD's promises that it was totally ready for GPGPU (if only people would write OpenCL!) but then discovering the horrible truth that this was very much not the case. AMD's OpenCL was dire. I wasted months into that flaming piece of trash -- twice! -- and really wish I hadn't. Both times I had to toss my code, sell my card, eat the spread, eat the ebay tax, and pay the green tax to buy a lower-specced nvidia card, but that all sucked a lot less than tossing my very own programmer months into a dumpster fire. Ironically, the very openness that was supposed to win converts from the green camp actually sent people in the opposite direction because you could run your OpenCL on an nvidia card and find out that actually the problem wasn't with your code but rather with AMD's drivers. Hopefully now that AMD has money they can afford the headcount to fix their bugs and some more headcount to make up for 15 years of lost time in the applications that matter. Hopefully. But I trusted them twice and got burned, so this time I need to see proof before I jump. I need to see blender renders, I need to see torch trainings, I need to see NAMD (or insert science code here) running on a compatibility layer. It is unfortunate that the actual compatibility situation seems to have hardly moved at all in 10 years (it was right around the corner in 2013 too, you see) but the fundamentals are different now so I hold out hope.
    - dragontamer 3y ago
      Lemme guess. You tried OpenCL 2.0 and found out it was a dumpster fire on AMD? OpenCL1.2 worked fine for all the test code I made for myself. But OpenCL 2.0 was... horrid. Unworkable. -------- My next step personally is to give DirectX 12 computer shaders a serious try. A lot of people are also talking about Vulkan shaders, as apparently that works well on Linux too. ROCm on Linux is fine enough. But this weirdness of having a feature on ROCm Windows (when ROCm Windows isn't even public yet?) is well... weird. I guess its cool that AMD has worked with the Windows team to get everything squared up, but it'd be nice if ROCm on Windows were available to the masses.
- jchw 3y ago
  NVIDIA cards have better Linux support roughly up until you connect a display output to the machine. AMD's issues are more general and not really a particular problem with their Linux support: they're spotty in general (bad drivers on card release, spotty OS support a la no ROCm on Windows.) In practice it obviously matters if you still can't get the features you need, but in my experience trying to run a modern Linux desktop setup with NVIDIA cards is absolutely second-class at this point. I tried my hand at it with a 2060 and the card was out of the machine in a month so I could have a stable desktop that actually resumed from sleep properly again. Granted, issues like that are very much case-by-case. Still; I can't even run SwayWM with NVIDIA as I do with AMD and Intel; even with patches to "fix" the flickering issues, XWayland stuff is broken. This makes no sense of course. It shouldn't need to be a snowflake case.
  - nsajko 3y ago
    > I can't even run SwayWM with NVIDIA as I do with AMD and Intel How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?
    - bombela 3y ago
      Same experience here. I get 4k 120hz over HDMI with my puny AMD laptop embedded GPU without tearing on Wayland. Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
    - jchw 3y ago
      Wayland does not contain any NVIDIA defeat devices, and neither does SwayWM. They just use standard Linux GPU interfaces. What I do know is that you can't use the same codepaths you'd use with countless other GPUs, again including AMD and Intel: NVIDIA cards need special cases. This is just as true for KDE and GNOME, which also do not work as well with NVIDIA under Wayland, despite having special codepaths for NVIDIA cards specifically. This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time. On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet. There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.
- thewataccount 3y ago
  > Just look at how many projects are using Linux and cuda and don't support AMD. That's because of the CUDA api specifically. For the display support it's very hit/miss. Somethings work fine, then you want to try Wayland and things get odd... When working correctly they Nvidia is mostly fine - Xorg games have support for everything except dlss3 AFAIK.
  - charcircuit 3y ago
    >That's because of the CUDA api specifically. No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. It's like saying an app only supports Windows because of the Windows API. If someone wanted to support multiple apps they wouldn't just use the Windows API.
    - thewataccount 3y ago
      > No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. AMD's implementation (ROCm) has historically been incredibly difficult to work with. As in their own examples won't compile. Historically if you even wanted to _touch_ data-science you had to have CUDA hardware/software (it's been improving a bit but alternatives are still lacking). > It's like saying an app only supports Windows because of the Windows API. It's a little more nuanced than that because the CUDA api is specifically for one set of tasks - data science. Nobody uses nvidia for their wide desktop support on linux - because it's terrible. Literally the only benefit of using nvidia + linux is either because of raw performance of the hardware and/or the cuda support. If you look at the arch wiki (applies to other OSes too) for anything graphics related you'll almost always seen specific sections dedicated to workarounds and fixes for nvidia hardware. If you don't believe me then try setting up wayland with nvidia drivers. Steam just had a fun issue where they were crashing on nvidia hardware with their latest redesign (no idea how they didn't catch that?!). These types of issues are commonplace, and are largely avoided by using AMD. thus why I say it's only really because of the cuda support.
SmoothBrain12 3y ago
[dead]
artemisart 3y ago
> Blender 3 taking so much time to give AMD Linux users hardware acceleration back makes me sad. I believe the issue comes from AMD which disable/doesn't support their GPGPU libraries on Linux and Blender cannot do much about it. GPGPU support in general is much much better on NVIDIA thanks to CUDA, both for Windows and Linux.
vanous 3y ago
I am with you, went for AMD too and I am having the same issues. I don't need 3D often, but occasionally I would like to/need to do something in Blender and though luck. I even tried rebooting to Windows, which I do like once in a few years, still no dice. Blender is super good and I love it and support it via plugin contributing. I keep my fingers crossed :)
thomastjeffery 3y ago
HIP works in Linux! You can use your GPU to render with cycles, you just can't use this specific feature of your GPU (yet). There's no reason to stick with Blender 2.8.
- Kye 3y ago
  The speed difference with ray tracing is substantial based on demos I've seen. At least with RTX.
  - thomastjeffery 3y ago
    I'm definitely excited to try it out, but it's not like we were completely missing GPU rendering without it.
    - Kye 3y ago
      No, but I do think it's reasonable for them to express frustration over missing out on a ~2x or better render speed improvement. It's like having a whole extra GPU installed but unusable.
      - thomastjeffery 3y ago
        Yes, but that's not my point. You don't have to keep using 2.8 to get GPU rendering in Linux.
        deleted 3y ago
        [deleted]
        doodlesdev 3y ago
        Only if you use the AMDGPU-Pro drivers, since it requires HIP. They only introduced HIP support in Blender 3.2: that's two minor releases (almost an entire year) without support for AMD GPU rendering at all. I should've made that clearer in my original comment. If there's a way to get HIP working under the Mesa drivers, I haven't been able to find it in my cursory searches through the internet. The newer versions of Blender only support CUDA and HIP as render devices, whereas in Blender 2.83 we still had the option to use OpenCL for rendering. You could say the blame is on AMD for giving subpar HIP support on Linux, and that would be fair IF the OpenCL backend didn't exist in Blender 2.83. Of course, to add insult to injury, they now don't port the RT acceleration to Linux, which just makes the experience truly inferior to Windows. As I pointed out in the original comment, this is a reasonable decision from a business standpoint. I just find it sad because Blender is one of the darlings of the open-source movement, so seeing them neglect Linux so much is frustrating.

charcircuit 3y ago

>because of better Linux support In my experience nvidia has better Linux support. Just look at how many projects are using Linux and cuda and don't support AMD.

doodlesdev 3y ago
Depends on what you're doing, which GPU you go for, etc. For my use cases switching from NVIDIA to AMD was a great decision. Also, if you're going to stick with open source drivers there is basically no comparison. Just for reference, what setup are you using? (Linux kernel, drivers, GPU, etc.)
iFire 3y ago
For example, on my AMD Linux test case, dual monitors and one with VR would be unstable. Nvidia handled it ok.
colechristensen 3y ago
AMD has much better open source drivers. nvidia gives you a binary blob... but it works better.
- wswope 3y ago
  That's out of date, I believe. Nvidia went open source last year, though they did that by moving a lot of code from the drivers over to their firmware (in binary blob form). https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
  - circuit10 3y ago
    That’s only for the kernel part, not the userspace part
  - opencl 3y ago
    Those open source kernel modules are not usable in any practical sense for consumer hardware in their current state. From the repo readme[1], "GeForce and Workstation support is still considered alpha-quality." [1] https://github.com/NVIDIA/open-gpu-kernel-modules https://github.com/NVIDIA/open-gpu-kernel-modules
    - captn3m0 3y ago
      Another limitation was in the GPUs supported - only the latest generation is supported, so no support for common consumer level cards - (1050, 1080 etc).
bee_rider 3y ago
It seems like Nvidia’s stuff is a bit more difficult to work with for the community, but the community puts a ton more effort into it.
- jjoonathan 3y ago
  The GPGPU community is full of a decade+ of bright-eyed bushy-tailed AMD fans who were painfully and traumatically pushed into the NVidia camp after believing AMD's promises that it was totally ready for GPGPU (if only people would write OpenCL!) but then discovering the horrible truth that this was very much not the case. AMD's OpenCL was dire. I wasted months into that flaming piece of trash -- twice! -- and really wish I hadn't. Both times I had to toss my code, sell my card, eat the spread, eat the ebay tax, and pay the green tax to buy a lower-specced nvidia card, but that all sucked a lot less than tossing my very own programmer months into a dumpster fire. Ironically, the very openness that was supposed to win converts from the green camp actually sent people in the opposite direction because you could run your OpenCL on an nvidia card and find out that actually the problem wasn't with your code but rather with AMD's drivers. Hopefully now that AMD has money they can afford the headcount to fix their bugs and some more headcount to make up for 15 years of lost time in the applications that matter. Hopefully. But I trusted them twice and got burned, so this time I need to see proof before I jump. I need to see blender renders, I need to see torch trainings, I need to see NAMD (or insert science code here) running on a compatibility layer. It is unfortunate that the actual compatibility situation seems to have hardly moved at all in 10 years (it was right around the corner in 2013 too, you see) but the fundamentals are different now so I hold out hope.
  - dragontamer 3y ago
    Lemme guess. You tried OpenCL 2.0 and found out it was a dumpster fire on AMD? OpenCL1.2 worked fine for all the test code I made for myself. But OpenCL 2.0 was... horrid. Unworkable. -------- My next step personally is to give DirectX 12 computer shaders a serious try. A lot of people are also talking about Vulkan shaders, as apparently that works well on Linux too. ROCm on Linux is fine enough. But this weirdness of having a feature on ROCm Windows (when ROCm Windows isn't even public yet?) is well... weird. I guess its cool that AMD has worked with the Windows team to get everything squared up, but it'd be nice if ROCm on Windows were available to the masses.
jchw 3y ago
NVIDIA cards have better Linux support roughly up until you connect a display output to the machine. AMD's issues are more general and not really a particular problem with their Linux support: they're spotty in general (bad drivers on card release, spotty OS support a la no ROCm on Windows.) In practice it obviously matters if you still can't get the features you need, but in my experience trying to run a modern Linux desktop setup with NVIDIA cards is absolutely second-class at this point. I tried my hand at it with a 2060 and the card was out of the machine in a month so I could have a stable desktop that actually resumed from sleep properly again. Granted, issues like that are very much case-by-case. Still; I can't even run SwayWM with NVIDIA as I do with AMD and Intel; even with patches to "fix" the flickering issues, XWayland stuff is broken. This makes no sense of course. It shouldn't need to be a snowflake case.
- nsajko 3y ago
  > I can't even run SwayWM with NVIDIA as I do with AMD and Intel How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?
  - bombela 3y ago
    Same experience here. I get 4k 120hz over HDMI with my puny AMD laptop embedded GPU without tearing on Wayland. Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
  - jchw 3y ago
    Wayland does not contain any NVIDIA defeat devices, and neither does SwayWM. They just use standard Linux GPU interfaces. What I do know is that you can't use the same codepaths you'd use with countless other GPUs, again including AMD and Intel: NVIDIA cards need special cases. This is just as true for KDE and GNOME, which also do not work as well with NVIDIA under Wayland, despite having special codepaths for NVIDIA cards specifically. This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time. On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet. There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.
thewataccount 3y ago
> Just look at how many projects are using Linux and cuda and don't support AMD. That's because of the CUDA api specifically. For the display support it's very hit/miss. Somethings work fine, then you want to try Wayland and things get odd... When working correctly they Nvidia is mostly fine - Xorg games have support for everything except dlss3 AFAIK.
- charcircuit 3y ago
  >That's because of the CUDA api specifically. No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. It's like saying an app only supports Windows because of the Windows API. If someone wanted to support multiple apps they wouldn't just use the Windows API.
  - thewataccount 3y ago
    > No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. AMD's implementation (ROCm) has historically been incredibly difficult to work with. As in their own examples won't compile. Historically if you even wanted to _touch_ data-science you had to have CUDA hardware/software (it's been improving a bit but alternatives are still lacking). > It's like saying an app only supports Windows because of the Windows API. It's a little more nuanced than that because the CUDA api is specifically for one set of tasks - data science. Nobody uses nvidia for their wide desktop support on linux - because it's terrible. Literally the only benefit of using nvidia + linux is either because of raw performance of the hardware and/or the cuda support. If you look at the arch wiki (applies to other OSes too) for anything graphics related you'll almost always seen specific sections dedicated to workarounds and fixes for nvidia hardware. If you don't believe me then try setting up wayland with nvidia drivers. Steam just had a fun issue where they were crashing on nvidia hardware with their latest redesign (no idea how they didn't catch that?!). These types of issues are commonplace, and are largely avoided by using AMD. thus why I say it's only really because of the cuda support.

SmoothBrain12 3y ago

[dead]

artemisart 3y ago

> Blender 3 taking so much time to give AMD Linux users hardware acceleration back makes me sad. I believe the issue comes from AMD which disable/doesn't support their GPGPU libraries on Linux and Blender cannot do much about it. GPGPU support in general is much much better on NVIDIA thanks to CUDA, both for Windows and Linux.

vanous 3y ago

I am with you, went for AMD too and I am having the same issues. I don't need 3D often, but occasionally I would like to/need to do something in Blender and though luck. I even tried rebooting to Windows, which I do like once in a few years, still no dice. Blender is super good and I love it and support it via plugin contributing. I keep my fingers crossed :)

thomastjeffery 3y ago

HIP works in Linux! You can use your GPU to render with cycles, you just can't use this specific feature of your GPU (yet). There's no reason to stick with Blender 2.8.

Kye 3y ago
The speed difference with ray tracing is substantial based on demos I've seen. At least with RTX.
- thomastjeffery 3y ago
  I'm definitely excited to try it out, but it's not like we were completely missing GPU rendering without it.
  - Kye 3y ago
    No, but I do think it's reasonable for them to express frustration over missing out on a ~2x or better render speed improvement. It's like having a whole extra GPU installed but unusable.
    - thomastjeffery 3y ago
      Yes, but that's not my point. You don't have to keep using 2.8 to get GPU rendering in Linux.
      - deleted 3y ago
        [deleted]
      - doodlesdev 3y ago
        Only if you use the AMDGPU-Pro drivers, since it requires HIP. They only introduced HIP support in Blender 3.2: that's two minor releases (almost an entire year) without support for AMD GPU rendering at all. I should've made that clearer in my original comment. If there's a way to get HIP working under the Mesa drivers, I haven't been able to find it in my cursory searches through the internet. The newer versions of Blender only support CUDA and HIP as render devices, whereas in Blender 2.83 we still had the option to use OpenCL for rendering. You could say the blame is on AMD for giving subpar HIP support on Linux, and that would be fair IF the OpenCL backend didn't exist in Blender 2.83. Of course, to add insult to injury, they now don't port the RT acceleration to Linux, which just makes the experience truly inferior to Windows. As I pointed out in the original comment, this is a reasonable decision from a business standpoint. I just find it sad because Blender is one of the darlings of the open-source movement, so seeing them neglect Linux so much is frustrating.