Blender HIP library libamdhip64.so loading issue in linux #109562

New Issue

Lee-Ringham · 2023-06-30T17:03:35+02:00

Lee-Ringham commented

2023-06-30 17:03:35 +02:00

System Information
Operating system: Linux-5.15.0-76-generic-x86_64-with-glibc2.29 64 Bits
Graphics card: AMD Radeon VII (VEGA20, DRM 3.42.0, 5.15.0-76-generic, LLVM 12.0.0) AMD 4.6 (Core Profile) Mesa 21.2.6

Blender Version
Broken: version: 2.82 (sub 7), branch: Unknown, commit date: Unknown Unknown, hash: rBUnknown
Worked: (optional)

Short description of error
Currently blender looks for these libraries when loading HIP:
libamdhip64.so and /opt/rocm/hip/lib/libamdhip64.so

libamdhip64.so is currently found in the package libamdhip64-dev

A non-developer might reasonably only have the libamdhip64-5 package installed (and not libamdhip64-dev) and thus, only have access to the library libamdhip64.so.5

Exact steps for others to reproduce the error
install hip
install blender
Edit > Preferences > System > HIP
No compatible GPUs found for path tracing...

Proposed solution
add libamdhip64.so.5 to the beginning of hip_paths so it is loaded first if available, but still falls back to libamdhip64.so if libamdhip64.so.5 is not found:

diff --git a/extern/hipew/src/hipew.c b/extern/hipew/src/hipew.c
index fda27f66aa1..87584f8bc52 100644
--- a/extern/hipew/src/hipew.c
+++ b/extern/hipew/src/hipew.c
@@ -238,7 +238,7 @@ static int hipewHipInit(void) {
   /* Default installation path. */
   const char *hip_paths[] = {"", NULL};
 #else
-  const char *hip_paths[] = {"libamdhip64.so", "/opt/rocm/hip/lib/libamdhip64.so", NULL};
+  const char *hip_paths[] = {"libamdhip64.so.5", "/opt/rocm/hip/lib/libamdhip64.so.5", "libamdhip64.so", "/opt/rocm/hip/lib/libamdhip64.so", NULL};
 #endif
   static int initialized = 0;
   static int result = 0;

**System Information** Operating system: Linux-5.15.0-76-generic-x86_64-with-glibc2.29 64 Bits Graphics card: AMD Radeon VII (VEGA20, DRM 3.42.0, 5.15.0-76-generic, LLVM 12.0.0) AMD 4.6 (Core Profile) Mesa 21.2.6 **Blender Version** Broken: version: 2.82 (sub 7), branch: Unknown, commit date: Unknown Unknown, hash: `rBUnknown` Worked: (optional) **Short description of error** Currently blender looks for these libraries when loading HIP: `libamdhip64.so` and `/opt/rocm/hip/lib/libamdhip64.so` `libamdhip64.so` is currently found in the package `libamdhip64-dev` A non-developer might reasonably only have the `libamdhip64-5` package installed (and not `libamdhip64-dev`) and thus, only have access to the library `libamdhip64.so.5` **Exact steps for others to reproduce the error** install hip install blender Edit > Preferences > System > HIP No compatible GPUs found for path tracing... **Proposed solution** add `libamdhip64.so.5` to the beginning of `hip_paths` so it is loaded first if available, but still falls back to `libamdhip64.so` if `libamdhip64.so.5` is not found: ```Diff diff --git a/extern/hipew/src/hipew.c b/extern/hipew/src/hipew.c index fda27f66aa1..87584f8bc52 100644 --- a/extern/hipew/src/hipew.c +++ b/extern/hipew/src/hipew.c @@ -238,7 +238,7 @@ static int hipewHipInit(void) { /* Default installation path. */ const char *hip_paths[] = {"", NULL}; #else - const char *hip_paths[] = {"libamdhip64.so", "/opt/rocm/hip/lib/libamdhip64.so", NULL}; + const char *hip_paths[] = {"libamdhip64.so.5", "/opt/rocm/hip/lib/libamdhip64.so.5", "libamdhip64.so", "/opt/rocm/hip/lib/libamdhip64.so", NULL}; #endif static int initialized = 0; static int result = 0; ```

Lee-Ringham added the

labels 2023-06-30 17:03:35 +02:00

Jesse Yurkovich referenced this issue

2023-07-01 22:29:54 +02:00

HIP related bugs #109431

YimingWu commented

2023-07-02 17:09:46 +02:00

Thanks for reporting and you managed to add it to HIP meta task. Appreciated!

YimingWu changed title from ~~Blender HIP library loading Bug Report~~ to Blender HIP library `libamdhip64.so` loading issue in linux

2023-07-02 17:10:47 +02:00

Brecht Van Lommel commented

2023-07-04 14:19:47 +02:00

I think following soversion conventions, it is indeed more correct to use .so.5, with major version bumps indicating API breaking changes we can't safely use .so.6. Perhaps that is why the .so is only part of the development package, with the intent of the application linking against .so.5. But I'm not sure if ROCm versions actually work that way.

If we can safely use ROCm 6, 7, 8, .. we can add a few more versions for future proofing. This would be to work around what is probably an issue better solved in packaging or ROCm.

@BrianSavery @Sayak-Biswas do you have any suggestion for what we can best do here, add .so.5 only, or add a few additional versions as well? Do you think this is worth reporting to Debian packaging or is it as intended?

I think following soversion conventions, it is indeed more correct to use `.so.5`, with major version bumps indicating API breaking changes we can't safely use `.so.6`. Perhaps that is why the `.so` is only part of the development package, with the intent of the application linking against `.so.5`. But I'm not sure if ROCm versions actually work that way. If we can safely use ROCm 6, 7, 8, .. we can add a few more versions for future proofing. This would be to work around what is probably an issue better solved in packaging or ROCm. @BrianSavery @Sayak-Biswas do you have any suggestion for what we can best do here, add `.so.5` only, or add a few additional versions as well? Do you think this is worth reporting to Debian packaging or is it as intended?

Brecht Van Lommel added

Module

Render & Cycles

Status

Needs Info from Developers

and removed