Here you go blender/blender#130153 Moving Blender away from ROCm 5 is a lot more straight forward that trying to support ROCm 5 and 6 at the same time. The…
@Alaska @Sergey I updated part of the code to handle the compatibility issue. https://projects.blender.org/blender/blender/compare/main...salipour:rocm-compatibility
It is not comprehensive,…
Faire enough. I will open a pull request to handle it.
@Sergey This is the problem with backward compatibility that I mentioned a while back. We can either leave it as is, and I'll update everything, including support for gfx12, for Windows and Linux…
Can you try changing all the "unsigned int" in HIP_MEMCPY3D to "size_t"?
@Sergey it is already in the list (libamdhip64.so is based on ROCm 6 runtime), you just need to change the order and look for it first.
@Alaska the workaround or rather the fix is to load libamdhip64.so instead of libamdhip64.so.5
It makes more sense to leave HIP-RT as is. Some of the issues/artifacts seem to be related to math functions, according to my colleagues. Also, it turns out gfx12 isn't reliably supported on SDK…
You might want to apply the same logic to HIP-RT compilation too, WITH_CYCLES_DEVICE_HIPRT.
@Alaska You are right the BVH build for HIP-RT fails when SDK version is updated. HIP-RT is hard-coded to look for hiprt${hiprt_version}_${hipsdk_version}_amd.hipfb where BVH builder is…
This is old and there is no benefit in adding it.
