Cycles AMD HIP device feedback

Hardware raytracing for AMD cards is on the todo list. I cannot give you more information about who and when. :slight_smile:

2 Likes

Correct, this is a code change only, avoiding code duplication.

Relying on translation will certainly have code redundancy resulting in performance loss, redundancy is a near-synonym, that word this I do not know how to say in English

Nice … What about Linux support for AMD GPUs. Thanks.

2 Likes

ping @bsavery
This is all silent at AMD while ROCm 5.0 / 5.1 is getting out of the oven :upside_down_face:

1 Like

Hey guys. My time is limited being on parental leave. Sorry there hasn’t been more updates, but the above statement still stands.

We’re also having another developer look at older card support but no guarantee there. As far as hardware ray tracing support we don’t have an optix like library ready yet for HIP and I can’t give any dates because of corporate reasons. And I’m not sure participating in the speculation on what is a developer forum is the best use of anyone’s time, to be honest.

I’ll give updates when we have them. Please understand companies like AMD don’t want to commit to things before they are ready and I’m telling you guys everything I can.

8 Likes

Hey Brian. Appreciate you taking the time during your leave to reply ( there has been no updates from the core dev team ).
With 3.1 Bcon3 starting on the 26th of Jan I really hope we can get AMD GPU support on Linux in by then or it stands to be left out for another blender release. Thanks.

1 Like

It’s more a question of when the driver will be available and when to get it. Which you can understand the corporate overlords don’t like to pre-announce. I’ll see if I can share more info but should be in the next few weeks.

3 Likes

I wish AMD the best of luck in delivering a driver that supports cyclesX and satisfies those that have purchased their products.

As for ray tracing I wouldn’t blame anyone for wanting “an order of magnitude increase in intersection performance”. :sunglasses:

2 Likes

Isn’t rays4.1 an off-the-shelf ray tracing library?

1 Like

Really, I have been waiting for HIP support for my Vega64 card, before moving up from 2.93.x to 3.x generation of blender. I am just unhappy looking at the gap between OpenCL removal and HIP replacement for it. The OpenCL option for rendering on GPU was still ‘bearable’.

I am keeping my hopes high for its inclusion in 3.2 alpha or 3.1 (stable) in next few weeks.

3 Likes

Hi,
Same for me with my radeon VII… waiting hard !

3 Likes

Looks like HIP RDNA Linux support will be pushed back to 3.2 which appears to be scheduled for June 8, 2022.

Its bad news for Linux RDNA owners. Strangely these days a delay is about as good as it gets for AMD GPUs when compared to the lack of commitment that Vega / Polaris owners are faced with. In other news Nvidia GPUs remain supported :joy_cat:.

3 Likes

There is some hope that ROCm version 5.x will be fully packaged in Ubuntu Jammy 22.04 LTS releasing April 21st 2022. 4.5.2 packages are still entering Debian:new. So that would be somewhat coinciding dates.
P.S. 20220129 lol, no way

While waiting for Blender acceleration, if you wish the ROCm/HIP stack success, you are welcome helping documenting it! :upside_down_face:

@bsavery since we are on a developer forum: would you or an involved AMD developer be kind enough to walk us through the challenges and technical designs that are being dealt with? I am guessing that graphic/compute interop is a big topic since it is not supported officially yet, but any more details and/or vulgarization would be enjoyed.

Linux RDNA2 users might have a chance to try a new 5.1 ROCM version soon.

Reasons this will amount to a hill of beans:

  • No word from AMD
  • Could be a typo as its a really strange place to mention release plans
  • ROCM 5.? has been pushed back several times.
  • ROCM 5.? might not fix what breaks Blender HIP.
  • Blender isn’t verified with ROCM.
  • Proprietary driver may or may not be released.
  • Proprietary driver may not be able to be tested with Blender as HIP is currently disabled.
  • AMD mentioned code changes are required to Blender 3.2 that have not been made.

Reasons to be excited:

  • You can’t become less supported than not supported.
2 Likes

As far as I understood, for Linux, Mesa-ROCm(HIP/OpenCL) graphics/compute interop is not even in the works yet, only interop with the proprietary graphics drivers… Communication from AMD is indeed bad on this subject.
Hopefully updates soon. https://github.com/ROCm-Developer-Tools/HIP/issues/2237

P.S. Interop is a very broad term, it binds compute kernels to graphics APIs, but it is not really defined anywhere. There is a huge surface area WRT APIs where interop is possible graphics{OpenGL, Vulkan} – compute{HIP, OpenCL}.
I suspect AMD of focusing work on AMDVLK or its proprietary vulkan driver, to the detriment of Mesa’s RADV. You could have interop with opencl, with opengl… the list and feature matrix can get big, I (we?) just don’t know what AMD plans.

1 Like

Enabling HIP alone in Blender is very easy, and it can be done by passing a couple of extra options to CMAKE, and obviously you have to compile from source. I’ve added this when editing AUR PKGBUILD for blender-git version:

-DWITH_CYCLES_DEVICE_HIP=ON \
-DWITH_CYCLES_HIP_BINARIES=ON \
-DCYCLES_HIP_BINARIES_ARCH=gfx900 \

where gfx900 is my Vega 64 arch from rocminfo output, I think RDNA 1/2 is included by default

If you have a non-RDNA GPU you also have to tweak some major/minor arch vars in util.h iirc, and I don’t actually know what they’re responsible for and noone will probably tell us, the old commit rB2f89ddc04377: Cycles: eliminate HIP architectures that fail to build that added HIP bins to be built for more GPU arches is now deleted, so just forget about it.

And building ROCm from source is an adventure of it’s own for several days with numerous build errors that have to be addressed every time. I just don’t bother anymore.

I feel so dumb now for picking Vega over RTX looking forward to years of support that AMD was known for at the time, for better support by open-source drivers. Nvidia proprietary Linux driver is horrible, there’s no overclocking or fan/power management support etc. But this thread just screams at me “Go buy Nvidia as soon as prices settle down and forget AMD GPUs as a bad dream!” Such a spit in the face of AMD users by essentially taking away GPU rendering, the lack of communication, this thread is a joke. At least AMD developed a great CPU to render with that doesn’t require “”“the driver”"" to work, but still times slower than GPU rendering.

3 Likes

Yup, sitting here stuck on 2.8 because my Vega 56 turns into a paperweight with Cycles X. But on OpenCL it’s hardly any better because the render kernel fails to compile like 60% of the time and crashes blender. Almost tempted to sell my vega for a ridiculous price while I still can.

1 Like

Since this stack is almost completely free and open-source, in theory anyone, with enough will and technical knowledge, is able to write their own graphics(OpenGL/Vulkan)/compute(HIP/OpenCL) interop and debug this Blender-Cycles-AMD-ROCm-HIP-Mesa-Linux thing.
I am almost seriously considering candidating to GSoC 2022 on this subject, depending on feedback from BSavery once he returns from parental leave.

@FogLizard compiling ROCm is almost acceptable now. There are still internal efforts at AMD to improve the build system, and people like Ye Luo and me are also trying to give a hand.

5 Likes

I am 2.9 began to contact blnder opencl except in 2.93 can not render the volume of other cases do not appear crashing problems, if frequent crashes I think it may be the first installation of the software for a few minutes of pre-compilation problems, it is recommended to delete the entire cache to recompile once, during the blind point do not rush to exit the software, in addition opencl each rendering of large scenes require a certain amount of pre-compilation time, rocm solves this problem.