Cycles AMD HIP device feedback

I did compile rocm from AUR like ten times over the past 11 months, and I don’t have time or will to do it any more. The result is always the same.

1 Like

3.3lts rendering speed is much slower,Don’t rush to update yet。

My 3.3.0 times are very similar to 3.2.0 on linux, as shown below.

Blender Version OS Mesa opencl-amd BAR Device Renderer Backend Tile Samples Notes averaged Run 1 Run 2 Run 3
3.2.0 5.19.2-arch1-1 22.1.6-1 [drm] Detected VRAM RAM=16368M, BAR=16384M RX 6800 (gfx1030) Classroom HIP – GPU 2048 300 00:41.83 00:41.83 00:41.77 00:41.88
3.3.0 5.19.6-arch1-1 22.1.7-1 [drm] Detected VRAM RAM=16368M, BAR=16384M RX 6800 (gfx1030) Classroom HIP – GPU 2048 300 00:41.20 00:41.33 00:41.13 00:41.13

However opendata does seem to show windows is now slower in 3.3.0 than 3.2.0

Why is my version 3.3 so slow 45s, or in the case of overclocking, the driver has also changed, win10 app store, and the official website exe are installed, all are 45s

I purposely downloaded version 3.22 to compare the run, the current driver is 22Q2 (I tested multiple versions of the driver, each time using the duu tool to uninstall)


  • There is a performance regression related to matrix inverse changes, will be looked into.
  • Hardware ray-tracing aimed for Blender 3.5.
    2022-09-20 Render & Cycles Meeting

Exciting. Initial work starts on October 26… Probably will be released in a proper release in Feb 2023



Sorry if this is off-topic, but does anyone know where to follow HIP development updates? I’d really like to know if/when polaris cards/my rx580 get support there.

1 Like

Can you elaborate from where you have taken those dates?

oct 26th probably the 3.5 release schedule that being said, i think the keywords in those meeting notes were “aimed for blender 3.5”. i mean I aim to floss more… however my dentist is quite aware aiming to floss more guarantees very little…

taking “we’re aiming for 3.5” as a commitment of “work starts on oct 26 and will ship in feb 2023” is a bit of a stretch imho

1 Like

For HIP development updates keep checking the Rendering Meeting Notes that are posted frequently. For your info unlikely HIP will ever support Polaris. Avoid AMD in the future.

1 Like

Yep its just me extrapoliating out what i think the 3.5 release date will be. Thats why I said probably. I have edited my post to make it clearer.

1 Like

Unfortunately further up in the thread both AMD and Blender have stated Polaris are unlikely to be supported officially.

I have read Polaris support is possible on Linux using an unsupported ROCM compilation switch but am not aware of widespread use or setup instructions.


Many users are in a similar situation. AMD does not care.


The user of RX580 is here.

Recently, I just have time to do some dig on blender with gfx803.
Unfortunately, it looks like not easy to support gfx803, even vega10 had been supported by blender-3.3. I didn’t have a vega10, just believe community had done the test. Looks like vega10 just need modify __popcll.

Here is some issues I met:

  • the kernels of cycles can be compiled sucessfully on gfx803, but it breaks on runtime. The result fatbin cannot get a properly result.
  • gfx803 cannot support debug, so I cannot debug kernels on gfx803 directly. That totally hang the investigation. Because we cannot print log in kernel on gfx803.

It is most likely there are issues on amdgpu-driver or llvm compiler because of successful compiling of cycles kernel, or there is mis-use on embed kernels asm codes. but it is really difficult to dig.

I will feed back if there is more useful infos. Please wish me luck. :slight_smile:


Apple Metal has support for the RX 580 for quite a while now. So its very possible, but AMD …

ROCm 5.3 is kinda out (no official annoucement yet), and I can happily confirm that HIP accelerated rendering finally works properly on RDNA1, the texture bug was fixed. I’ve not benchmarked it yet, but it sure feels quite a lot faster than CPU rendering. Great job @bsavery and @sayakAMD , and thanks a lot!

I know, not sure when that announcement is coming. But should fix the issue on RDNA1 and Vega.

Regarding Polaris, the hip runtime side isn’t going to be fixed for a new app for them to support here, so if something concrete is found I can file bugs to the rocm team, but they most likely won’t be fixed here.

What do the developers think about adding a note to the HIP – AMD section of the manual to state their is a known unresolved issue with CyclesX when used with a RDNA2 GPU under Linux that result in the graphics driver crashing?

There are multiple accounts of this crash, which have not been resolved, such as:

If you have time (and are one of the very few that use Blender on Linux with RDNA2) please report your stable / unstable Linux setups over at 2145.


Hi there,

Thank you for spreading the word of the issue and my amd/drm ticket here!

I agree that this issue should be mentioned somewhere in the Blender docs as it makes Blender pretty much unusable for Linux-users with RDNA2 AMD GPUs.

What makes me a bit nervous about the decision they will take:
I read in the AMD ROCm Docs, that GUI-based software is actually not supported
(which also makes me question the blender developers decision to move to it).

I really do hope they will fix it though.


They decided to move to it because it’s more or less the only choice. OpenCL is more or less deprecated for all practical purposes. :frowning: Starting a new project in OpenCL is not really future-proof atm.

1 Like