Closed Nielsbishere closed 1 year ago
Hi,
amdhip64.dll is part of the AMD GPU driver so it could/should not be shipped separately. You could try to update the AMD driver, maybe that will fix it. Could you share what driver version and AMD CPU are you using?
OIDN doesn't actually support any integrated AMD GPUs so it doesn't even try to use them, it just queries the list of HIP devices, and it seems this is where HIP crashes. The issue seems to be a variation of the bug in the HIP driver that was causing issues before v2.0.1. If you could share the exact AMD CPU model you have, maybe we could add another workaround but this is a fundamental bug in the HIP driver which should be fixed. So probably it would be best if you could contact AMD about this.
Hi, It seems like I didn't double check our QA to update the driver of the integrated gpu. It seems to work if you manually update the AMD driver (the one shipped with windows doesn't work). The CPU is a Ryzen 5 Pro 5650G and the driver that didn't work was from 30 March 2023 (31.0.12027.9001). When I tested the latest (31.0.21029.1006 released at 14 Aug 2023) it seems to work again. Thanks for the heads up 👍
Hi, when testing on a system with an AMD cpu with an integrated GPU and an nvidia GPU, we're seeing a crash on oidnGetNumPhysicalDevices. This crash is present even with v2.0.1; I was hoping the changelog about fixing something with AMD gpus was also true for us.
In production this shows up as the device from LUID function crashing, but when trying to dig deeper by looking at why I hit a roadblock at oidnGetNumPhysicalDevices (because it initializes the context, which crashes). It seems like this function ends up calling amdhip64.dll which causes a crash. I've built this OIDN version from source to see the symbols, but it's also happening in the release.
Do you know how to acquire amdhip64.dll and amdhip64.pdb, or is this just an internal Windows thing that AMD ships? I've looked at the manual HIP build and found no dll, though it did successfully build and produce a lib (tried turning on/off their option for static libraries too). It also produced the OIDN hip dll. My guess would be that the amdhip64 is incompatible, but without supplying a manual amdhip64.dll we can't prevent fallback to the default (crashing) version. If this is not possible to fix in oidn, I'll have to contact AMD about fixing it in HIP instead.
In release we will be deleting the OpenImageDenoise_device_hip.dll, since HIP itself is not supported properly in Windows anyways. Once we have confirmation from AMD that LUID is supported, we will be enabling it again.
Thanks for the help.