I'm trying to use HIP in Blender to render things on the GPU, but lately, every attempt to do so results in crashes. I'm currently using Blender 4.3.2, and dev-util/hip-6.1.2. Looking at the backtrace in gdb, it's clear that the issue is that, at some point, the LLVM 18 library suddenly calls into the LLVM 19 library: #0 in llvm::MachinePointerInfo::getAddrSpace() const () at /usr/lib/llvm/19/lib64/libLLVM.so.19.1 #1 in ??? () at /usr/lib/llvm/19/lib64/libLLVM.so.19.1 #2 in llvm::FoldingSetBase::GetOrInsertNode([...]) () at /usr/lib/llvm/18/lib64/libLLVM.so.18.1 This backtrace goes back further through LLVM and Clang, all version 18, until you reach code from rocm-comgr. At this point, I've got no clue what exactly is causing the issue, I can only see that something is causing two versions of LLVM to get loaded into memory, and somehow one version sees fit to call the other. To clarify, both blender 4.3.2 and hip 6.1.2 only support LLVM 18, so if it were working that's the only version we'd be seeing. LLVM 19 shouldn't be showing up here. (There's a new version of hip that *does* support 19, but blender hasn't caught up yet.) I don't know where the blame ultimately lies, but it's clear that *something* isn't working right. Personally, looking at the ebuild, I wonder if the mesa LLVM_USEDEP restraint for OSL support shouldn't also be applied to HIP support. If that is where the unwanted LLVM 19 is coming from, then that would probably be the solution, but I don't know how to check what specific part of the system is causing LLVM 19 to be loaded in. At the same time, if blender can be upgraded to LLVM 19 then it should do so, since I imagine trying to get rid of it after having it installed would be quite annoying. Reproducible: Always
Please include the full backtrace and emerge --info blender and any other relevant packages.
