gfx1035 is listed as APU on User Guide for AMDGPU Backend — LLVM 15.0.0git documentation, and that’s the list we are going off since it should correspond to how LLVM compiler in the HIP SDK treats it. The bug report also mentions “Rembrandt RDNA2 IGP”, where IGP means integrated.
Also it’s not obvious to me that switchable graphics means that one of the two GPUs is necessarily dedicated. Maybe but I’m not sure.
Actually @brecht gfx 1035 can be enabled I think. We have tested internally, and the only issue is with the older HIP sdk it would throw a warning of an unknown architecture. The one installed on build bots now should be fine with it.
Hello Dear Blender Devs, i have noticed that in the task ⚓ T91571 Cycles HIP device
the “Linux support and stability” lacks the polaris architecture, but the polaris gfx8** architecture supports HIP at least it does in linux as shown in the output of my personal machine :
/opt/rocm/hip/bin/hipInfo
I only added Vega because that’s planned to be worked on. Polaris may or may not happen, but I don’t want to give the impression that it is on the roadmap. Those cards are no longer listed as supported GPUs in the ROCm docs, so even if we do get it working at some point, that may be difficult to maintain.
So after removing Rocm 5.1.3 I’ve been able to compile Blender 3.3 alpha from git finally with no HIP or Vega support obviously. Something is still broken in Rocm 5.1.3 (or in Blender itself) so latest Blender will fail at generating HIP kernels during compilation, at least on Arch with the AUR version.
I did that and blender-git builds now skipping fatbins with Vega enabled. But it still doesn’t render with “hip hipcc compiler not found, install hip toolkit in default location” error. I don’t know how to address that.
I’m not on my PC at the moment to check but it’s possible that you are missing files included in the opencl-amd-dev package. (It’s a big package about 9-10GB)
To be clear, getting Vega to work is not a matter of build configuration or applying existing patches, there are other issues to be fixed still. Otherwise we would have enabled it already.
Since we’re already at Bcon4, just a few days away from the scheduled release, and with no update from Sayak, looks like RDNA support is gonna slip again?
Edit: Or are we actually running into a bug in HIP itself? AMD seems to prepare another release, I see an activity spike on the repos, which usually happens right before an update.
Not only that but AMD confirmed that RDNA will not be supported for ROCm so don’t get your hopes up. I enjoyed having this GPU in these crazy times but I’ve completely abandoned the idea of doing anything else other than gaming with it.
Some scenes do work just fine though, which means there’s clearly a workaround at least. But I don’t understand why they don’t cause Blender to crash. Junk Shop renders just fine, and looking at the log, I see many of the same hipTexObjectCreate calls that normally cause immediate segfaults, except they execute without issue in this particular scene.
@Luciddream . I work for AMD The driver team is only currently supporting RDNA2 for Blender with HIP. However, we’re doing what we can to make sure RDNA is enabled in Blender.
@wsippel I’m not sure what makes you say “clearly there is a workaround”. It’s just some scenes don’t cause the issue. It does seem to be in the hipTextureObjectCreate call, the driver team is looking at why its only on the RDNA cards.
Well, I dug around some more to figure out why Junk Shop works. There appears to be a workaround, it’s just not a very convenient workaround: As far as I can tell, what’s causing the crash is textures with an odd horizontal resolution (odd vertical resolution is fine though). I made a bunch of test textures in different resolutions. 2048x2048, 4096x4096, 2048x4096, 768x4096 and 1024x1023 all worked, 2047x2048 crashed.