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.
2 Likes
Many users are in a similar situation. AMD does not care.
4 Likes
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. 
3 Likes
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:
- Above in this thread
- Blender Issue tracker (closed without resolution, AMD dev also found it crashed blender) T100353
- kernel . org issue tracker 216200
- drm/amd issue tracker 2145 and 2190
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.
2 Likes
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.
2 Likes
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. 
Starting a new project in OpenCL is not really future-proof atm.
1 Like
Hi Brian.
Right now I haven’t got clear clues on whats wrong about gfx803.
I have to say it is so plainful for testing gfx803, because of lacking debug feature. I almost spent one month to test gfx803 with ROCm-5.2.3, and it always report Mem Fault error. At I nearly accept the fact and give up. ROCm-5.3 released, The mem fault disappeared. Thank godness, Finally I got a kernel_gfx803.fatbin just can render scene_cube_surface.xml properly.
What I modified is replace all noinline to inline, and yes, then image turn 10 times larger than normal, also the compiling time.
It seems like there is something fixed in kernel or llvm for ROCm-5.3. But it really difficult to find out.
It is really appreciate if there are documents or tools for debuging old card, like gfx803, polaris. Or, could AMD provides training for debug amdgpu assemble codes?
I will do some test next week.
2 Likes
I test blender-3.3.1 with ROCm-5.3.0 and RX580 (gfx803).
It can render successfully on Ubuntu-20.04.5.
I had upload pre-build binary to github. Someone who interested could have a try.
7 Likes
Nice job @Xu-Huisheng ! The ROCM team isn’t officially supporting Polaris AMD ROCm Hardware and Software Support Document - AMD Community, and up to this point it hasn’t worked in blender, which is why we haven’t enabled it. And would be interesting to try this on windows as well.
All that being said I think this is great to have as an option for users to compile themselves.
2 Likes
@bsavery
It will be more convenience if there is a parameter to control whether we can select gfx8+ or gfx9+ (default) on cycles.
Right now, the enabled version range is hard coded in the util.h, I have to compile whole blender and distribute this about 200MB package.
If we can enable gfx8+ with some environment variable, I can just upload kernel_gfx803.fatbin to other person.
Actually, I didn’t have a windows development envrionment, cannot build windows blender version for gfx803 and test. If there is a option to enable gfx8+ without rebuild whole blender, I can do some test too.
2 Likes
I’m ok with it, if it’s hidden behind an env variable but it’s a bit up to @brecht so I’ll defer to his thoughts here.
1 Like
ROCm 5.2.3-1 landed in Debian unstable repo, so I gave it a try.
AMD documentation states: **NOTE**: This release of ROCm is validated with the AMDGPU release v22.20.1.
Which should be enough as Blender requires at least 22.10.
Unfortunately Blender is not detecting GPUs (Vega II) so far:
I don’t know if this is because Debian unstable have 6.0 kernel, and ROCm does not like that, or is it something else. I don’t expect ROCm to work OOTB with unstable and unsupported Linux distro. But I can provide all necessary system info if needed to help with enabling Blender on Debian with packaged ROCm drivers.
2 Likes
We could change the logic so that if a binary exists for the architecture, it uses that without checking if the architecture is supported. I don’t think it needs an environment variable.
3 Likes
Has the checking logic been changed ?
Came across this … OneAPI has CYCLES_ONEAPI_ALL_DEVICES=1
Is there anything like this for HIP ?
For HIP we’ve always only supported the specific architectures that we ship binaries for, that hasn’t changed.
For OneAPI this all devices option is possible because there is runtime compilation for different architectures, which we don’t have for HIP at the moment.
1 Like
I meant this change " We could change the logic so that if a binary exists for the architecture, it uses that without checking if the architecture is supported. "