我记得amd的linux显卡驱动没有Arch，只有ubuntu、centos、rhel、sled这四个驱动版本，另外我在youtube上看到之前windows与ubuntu的评测，渲染无论是cpu还是cuda都比linux慢很多。
1 Like
Hi there. Are the summary of users having issues based on 5X00 series cards? ⚓ T97591 Address boundary error rendering with HIP on Linux, maybe RDNA1 specific
This issue from @wsippel ? 6X00 seems ok?
Just to recap you need the ROCM 5.1 driver or the upcoming closed source driver based off it and the latest blender build.
Yes I’m also having the same error and have a 5700XT. (build 179100c02126). I now have a new CPU (5900x) and can tests patches / builds more easily, in case you want us to try something.
My 6800 works on Linux ok as per my post above, however I am not using a configuration that AMD supports.
After a bit of use only issues have been:
- Random GPU crashes, however this may be related to a longstanding issue with AMD on Linux not specific to Blender, hopefully it can be fixed.
- Using a 16k world background renders on CPU, but HIP GPU gives the following error
Invalid value in hipTexObjectCreate(&cmem->texobject, &resDesc, &texDesc, __null) (intern/cycles/device/hip/device_impl.cpp:1083)
To clarify, when you say “driver”, are you referring to the kernel driver itself? If so, I’m pretty sure neither ROCm package on Arch installs the closed source kernel driver. There is a package for the DKMS driver (amdgpu-pro-installer), but I’d prefer not to mess with that if at all avoidable, so it would be very much appreciated if you could specify.
I also just tested again, with ROCm 5.1.1, the latest Blender nightly, and kernel 5.17.5 (which admittedly had no amdkfd fixes over 5.17.4 IIRC), still crashes in hipTexObjectCreate.
@bsavery just wondering if there has been any movement on HIP-RT for cycles… totally understand if there is nothing you can talk about right now!
1 Like
1 Like
I remember vega no rt, rdna2 began to have rt
How to forcibly turn on hip support for GPUs that are not in the list support range, such as radeon rx680m of rdna2 mobile platform? Is there anything like Environment variables such as CYCLES_ HIP_ SPLIT_ KERNEL_ TEST=1?
The main way of using AMD GPUs that are supported by the Cycles HIP implementation (E.G RDNA2 Mobile) but not supported with the pre-compiled kernels found in the release build of Blender is to compile Blender from the source code yourself with that specific device enabled.
You can find a guide on how to build Blender here: Building Blender - Blender Developer Wiki
However, along side that you also need the HIP SDK. I don’t believe the HIP SDK is publicly available on Windows, and as such you may not be able to use this approach on Windows unless the HIP SDK is make available (I may be wrong about this part).
The HIP SDK is publicly available on Linux if you’re using that.
Sadly, at the moment there are no documentation I can find that details how to configure the Blender build with the HIP SDK. So you may need to seek advice from others or figure it out yourself.
I’m sorry if this isn’t particularly useful.
Hello,
I’m currently on blender 3.1 and I noticed that rendering on my RX 6700 XT GPU was extremely slow. It was something like 5 or 6 times slower than expected based on benchmarks on the internet. I tried turning off SAM (smart access memory/resizable BAR) and it seems to have resolved the issue.
CPU: AMD Ryzen 5 3600
RAM: 2133 Mhz (slow because of compatibility issues between the modules and the Ryzen platform but stable and consistent)
GPU: AMD RX 6700 XT
GPU Driver Version: 21.50.02.01 AMD-Software-Adrenalin-Edition
I’m not sure what other information to include so here are my observed rendering times:
To test, I rendered ‘Classroom’ at 150 samples 4 times using different device settings.
Render 1
Device: GPU Compute (HIP)
SAM/Resizable BAR - OFF
Rendering time: 32.59 seconds
Render 2
Device: GPU Compute (HIP)
SAM/Resizable BAR - ON
Rendering time: 2 minutes 46.93 seconds (412.2% slower than SAM OFF)
Render 3
Device: CPU
SAM/Resizable BAR - OFF
Rendering time: 4 minutes 57.93 seconds
Render 4
Device: CPU
SAM/Resizable BAR - ON
Rendering time: 5 minutes 3.05 seconds (1.7% slower than SAM OFF, probably mostly due to stock cooler)
Sorry if the information provided is insufficient or pedantic I just never know what to include.
I may also note that in other applications SAM doesn’t have this big of an effect on performance on my specific hardware. Usually, the difference is within a few percentage points, if that, from what I’ve seen.
1 Like
Tested again with ROCm 5.1.2 and 5700XT, getting the same error.
:3:hip_texture.cpp :1453: 9415878854 us: 48646: [tid:0x7f43ddfff640] hipTexObjectCreate ( 0x7f4,2a8,172,9e8, 0x7f4,3dd,fb9,140, 0x7f4,3dd,fb9,0d0, char array:<null> )
:4:rocdevice.cpp :2034: 9415879067 us: 48646: [tid:0x7f43ddfff640] Allocate hsa device memory 0x7f41d9e00000, size 0x169000
:3:rocdevice.cpp :2073: 9415879071 us: 48646: [tid:0x7f43ddfff640] device=0x7f43ceaef800, freeMem_ = 0xfa142710
:4:rocdevice.cpp :1899: 9415879196 us: 48646: [tid:0x7f43ddfff640] Allocate hsa host memory 0x7f43e7de8000, size 0x110
Writing: /tmp/classroom.crash.txt
fish: Job 1, 'AMD_SERIALIZE_KERNEL=3 AMD_SERI…' terminated by signal SIGSEGV (Address boundary error)
./blender' terminated by signal SIGSEGV (Address boundary error)
classroom.crash.txt (2.4 KB)
Looks like SAM has an issue on windows with Blender, my Linux setup only marginally improves when disabling SAM. Tested with Classroom 300 samples RX6800.
SAM / BAR enabled - 3 run average 00:41.26
[drm] Detected VRAM RAM=16368M, BAR=16384M
SAM / BAR disabled - 3 run average 00:40.81
[drm] Detected VRAM RAM=16368M, BAR=256M
1 Like
Just confirming the opencl-amd package you help maintain still works with my RX6800 (5.1.2 is even a little faster than 5.1.1). Keep up the great work!
AMD should prioritize getting this working on Linux RDNA. Hopefully their is some more info in the fortnightly cycles meeting … if it happened / gets posted.
| Blender Version | OS | Mesa | opencl-amd | Device | Renderer | Backend | Tile | Samples | Run 1 | Run 2 | Run 3 | Average |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 3.2.0 alpha (179100c02126) | 5.17.1-arch1-1 | 22.0.1 | 5.1.1 | RX 6800 (gfx1030) | Classroom | HIP – GPU | 2048 | 300 | 00:46.04 | 00:46.12 | 00:46.14 | 00:46.10 |
| 3.2.0 alpha (179100c02126) | 5.17.5-arch1-1 | 22.0.3-1 | 5.1.2 | RX 6800 (gfx1030) | Classroom | HIP – GPU | 2048 | 300 | 00:41.42 | 00:41.22 | 00:41.13 | 00:41.26 |
1 Like
I’ve updated to Blender 3.3 Alpha today, and I have Rocm 5.1.1 compiled with open source mesa driver. When I go to preferences - system I have HIP tab now, but it states that I don’t have a compatible RDNA device. Wasn’t Vega support supposed to be enabled in 3.3?
Vega support was enabled in Blender 3.2, but then was later disabled due to major bugs. These bugs are being investigated and Vega support may be re-enabled in the future.
As of today, Vega support has not been re-enabled in Blender 3.2 or 3.3 (to my knowledge).
TECHGAGE have updated their Blender testing for 3.1. Their Cycles testing appears to align with the blender.opendata tests with a RX6900 approximately equivalent to the RTX3050 / RTX3060.
Interestingly the author suspects ray-tracing in cycles won’t arrive before RDNA3. I am more worried RDNA2’s ray-tracing hardware will remain unsupported like the present state of Cycles support for RDNA on Linux, Vega and Polaris. 
Hardware accelerated ray tracing for Cycles HIP is being worked on. It will become available when it becomes available. That could be before, or after the release of RDNA3.
As for support on Linux, and support for Vega. Both are being worked on/fixed.
1 Like
All I see is a couple of issues reported on Windows here:
https://developer.blender.org/T96740
Was it ever enabled on Linux? Can it be enabled on Linux for any testing at all? Windows and Linux have entirely different drivers, so I don’t understand how investigating issues on Windows would help Linux support for Vega.
RDNA1, Vega and Polaris didn’t have dedicated hardware for raytracing, so it makes some sense. I find it very plausible that it won’t be ready until RDNA3’s release, but that doesn’t mean that RDNA2 support is going to be dropped because a new generation came out, there’s just no excuse for it.