fcfa64f230
Merge branch 'rocm-compatibility' of projects.blender.org:salipour/AMD_HIPRT into rocm-compatibility
@Alaska so it is not the same root cause as this one blender/blender#130153?
I was testing the PR. The HIP works as expected, but trying to render with HIP-RT crashes. Is this expected behavior until we re-compile the hiprt library on Linux?
Yes, it is…
I don't know if hiprt is currently shipped with the rest of ROCm package. But, if it is, it might not necessarily be the same version that is intended for Cycles.
@Sergey I updated the code based on your feedback and also tried the changes on Linux. I am surprised I wasn't getting the same build error on Windows
Does the HIP-RT "know" which HIP SDK it was compiled with?
Actually, yes. You can read it from a header, so you would know the version at build time. So, If the SDK version HIPRT was compiled…
AFAIR, we don't have multiple ROCm/HIP SDKs installed in the build environments, so the HIPRT is compiled with the same ROCm/HIP version as Blender?
I am concerned about a situation where…
@Sergey Another sticking point for 4.3: If Cycle kernels are compiled with SDK 6+, then Rocm 6+ runtime will be loaded. This logic should also apply to HIPRT, because HIPRT loads the runtime as…
Meaning doing away with FindHIP.cmake and move the logic to hipew project?
I thought so too. But, the CMake file in hipew_extern wouldn't recognize it if it wasn't cached. Maybe it was for a different reason. Anyway, if it works without caching, even better.
@Alaska you can continue to use 5.7 kernels and load amdhip64.dll (ROCm 5 runtime) on Windows, but ROCm 5 will not receive any update, bug fix or support for new hardware. We might be able to get…
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…