Fix #119444, #118709: Crash in OIDN GPU detection for unsupported HIP device #119448

Brecht Van Lommel · 2024-03-14T05:03:20+01:00

Brecht Van Lommel commented

2024-03-14 05:03:20 +01:00

Another attempt, since the previous fix was not enough. This disable OIDN for
HIP entirely if any unsupported HIP device is present.

Changing the device initialization order I think is a risky change, and I'd
really rather not do it at this point in the release cycle.

Another attempt, since the previous fix was not enough. This disable OIDN for HIP entirely if any unsupported HIP device is present. Changing the device initialization order I think is a risky change, and I'd really rather not do it at this point in the release cycle.

Brecht Van Lommel force-pushed fix-oidn-hip from a5e5a8fc4a to daa8e28215

2024-03-14 05:11:16 +01:00

Compare

Brecht Van Lommel force-pushed fix-oidn-hip from daa8e28215 to 0ca76e9f34

2024-03-14 05:17:22 +01:00

Compare

Brecht Van Lommel commented

2024-03-14 05:18:19 +01:00

@blender-bot package windows-amd64 linux

Blender Bot commented

2024-03-14 05:18:21 +01:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR119448) when ready.

Brecht Van Lommel commented

2024-03-14 05:25:42 +01:00

This fix isn't correct because we will just initialize e.g. OptiX devices, without running the code that detects if there are unsupported HIP devices.

The issue is that I do not want to run HIP initialization at all if HIP was not selected, because we've had issues in the past where drivers would crash, also before OIDN. But in order to detect which devices may crash OIDN when initializing an OptiX device, we have to initialize HIP...

So at the moment I don't have a good Cycles side fix for this. I guess what we'd need is some way for OIDN to initialize individual device types instead of all of them at once.

This fix isn't correct because we will just initialize e.g. OptiX devices, without running the code that detects if there are unsupported HIP devices. The issue is that I do not want to run HIP initialization at all if HIP was not selected, because we've had issues in the past where drivers would crash, also before OIDN. But in order to detect which devices may crash OIDN when initializing an OptiX device, we have to initialize HIP... So at the moment I don't have a good Cycles side fix for this. I guess what we'd need is some way for OIDN to initialize individual device types instead of all of them at once.

Deniil Ekimov commented

2024-03-14 09:27:44 +01:00

First-time contributor

Package build started. Download here when ready.

Thank you for your work. This build still crashes for me. Tell me if there is anything I can provide, I will be glad to help

> Package build started. [Download here](https://builder.blender.org/download/patch/PR119448) when ready. Thank you for your work. This build still crashes for me. Tell me if there is anything I can provide, I will be glad to help

Deniil Ekimov commented

2024-03-14 09:51:21 +01:00

First-time contributor

Updated AMD Radeon drivers and it works now without crashes. Thank you!

Brecht Van Lommel added 1 commit 2024-03-14 12:33:31 +01:00

8aceec2575 Try patching OIDN to dynamically init HIP device

Brecht Van Lommel referenced this pull request

2024-03-14 13:24:30 +01:00

"hipErrorNoBinaryForGpu: Unable to find code object for all current devices!" with nVidia GPU and AMD iGPU #119444

Brecht Van Lommel referenced this pull request

2024-03-14 17:08:15 +01:00

"hipErrorNoBinaryForGpu: Unable to find code object for all current devices!" with nVidia GPU and AMD iGPU #119444