[Tracking] AMD GPUs and NixOS - 'Cannot find target for triple amdgcn-- Unable to find target for this triple (no targets are registered)'.

[shymega]

Issue description

I've been experiencing a bug with my AMD iGPU (780M), but it appears this is a bug affecting more than a few NixOS users.

For me, it affects 1Password, and dwl. I'm also having issues with Steam crashing when the web component loads. I am curious if this is related, but I am certain 1Password and dwl are affected by the amdgcn triple error.

This issue, therefore, will act as a tracking issue.

Below is a list of issues I've found with the characteristic signature error:

343580

340196

339520

There has been talk of a possible Mesa bug causing this.

[Eisfunke]

My guess this is a problem with a mismatch of the Mesa version between the one used by the system and for building the package rather than a bug in Mesa itself. This seems to fit the pattern so far as all of the issues you linked mention using an unstable package. I experience the same bug with launch unstable youtube-music, an Electron app, but the stable package is fine.

Currently mesa is at 24.0.7 on stable and at 24.2.2 on unstable. There was a minor update for mesa on unstable from 24.1 to 24.2 last month (see https://github.com/NixOS/nixpkgs/commits/nixos-unstable/pkgs/development/libraries/mesa/common.nix), so this might be what launched the recently increased amount of problem reports.

To confirm the mismatch is the problem it'd be interesting if someone tried running the affected package unmodified, but on an unstable NixOS.

My guess stems from the fact that when I had problems with Vivaldi (which is based on Chromium) not starting in the past that I was able to fix by overriding the mesa input:

(pkgs.unstable.vivaldi.override { mesa = pkgs.mesa; })

If this is the problem, I guess it isn't actually be a bug or something nixpkgs could fix. Although noting somewhere that using unstable chromium/electron on a stable NixOS is problematic and providing an easy override for the mesa input would be helpful.

[shymega]

Hm, that's an interesting hypothesis.

For my use with dwl, I'm currently using nixpkgs-master (so I can use dwl v0.7), but I will try overriding Mesa on that.

EDIT: I was too naive. I can't just 'override' Mesa on dwl like that.

[shymega]

OK, so I did try and override wlroots and pass that modified derivation to dwl. I'm still working it out, but it seems by overriding the Mesa input of wlroots, it then can't find things like libdrm or cmake.

We should likely document this behaviour with Mesa, though.

[KczBen]

I stumbled upon this issue when searching for the error message. For what it's worth, this is also happening on Debian Sid/unstable at the moment, with Mesa 24.2.3. Downgrading to Mesa 24.2.2 fixes the issue there.

[shymega]

Yeah, it may well be an upstream issue then. Do you have a link to a Debian Sid bug report?

We might need to work together across distros/packagers to fix this. Perhaps there's a breaking change with Mesa.

[KczBen]

I don't see a report yet for Debian, though I may just be looking in the wrong place since Mesa has lots of packages. I'll see if I can make one once I find the package that's causing the issue

[shymega]

My guess this is a problem with a mismatch of the Mesa version between the one used by the system and for building the package rather than a bug in Mesa itself. This seems to fit the pattern so far as all of the issues you linked mention using an unstable package. I experience the same bug with launch unstable youtube-music, an Electron app, but the stable package is fine.

Currently mesa is at 24.0.7 on stable and at 24.2.2 on unstable. There was a minor update for mesa on unstable from 24.1 to 24.2 last month (see https://github.com/NixOS/nixpkgs/commits/nixos-unstable/pkgs/development/libraries/mesa/common.nix), so this might be what launched the recently increased amount of problem reports.

To confirm the mismatch is the problem it'd be interesting if someone tried running the affected package unmodified, but on an unstable NixOS.

My guess stems from the fact that when I had problems with Vivaldi (which is based on Chromium) not starting in the past that I was able to fix by overriding the mesa input:

(pkgs.unstable.vivaldi.override { mesa = pkgs.mesa; })

If this is the problem, I guess it isn't actually be a bug or something nixpkgs could fix. Although noting somewhere that using unstable chromium/electron on a stable NixOS is problematic and providing an easy override for the mesa input would be helpful.

Hey @Eisfunke - just wanted to get your thoughts on my fix for dwl here. I was going to document it on my wiki once I get it working.

[shymega]

I don't see a report yet for Debian, though I may just be looking in the wrong place since Mesa has lots of packages. I'll see if I can make one once I find the package that's causing the issue

No rush, if you're able to get anywhere, let us know! Thanks.

[KczBen]

I updated my Debian machine to Mesa 24.2.3 again, and rather annoyingly everything just works now. There was no Mesa nor LLVM version change in Debian, so I can't really blame any package for causing this. I wonder if it's something cache related? There were issues before with Chromium/Electron applications having broken rendering after a Mesa update, and wiping the application's shader cache resolved those.

[shymega]

Yeah, that could be why. However, I can't see a dwl cache in $XDG_CACHE_HOME.

[KczBen]

I don't know where dwl puts its cache, so I can't help with that sadly. But for Electron apps, they put their shader cache in ~/.config/<app_name>/GPUCache, because... Electron. That's just how they do things.

[AgentElement]

I could not reproduce this with dwl, but mpv and prusa-slicer also have this issue.

[NyCodeGHG]

I got this error while trying to package an app with electron_31, while my system is on 24.05

[shymega]

I could not reproduce this with dwl, but mpv and prusa-slicer also have this issue.

Are you using dwl v0.7? That's the issue I'm having. My repo is currently private, whilst I try and prepare for a work laptop.

[shymega]

I've just made the repo public again.

@AgentElement I meant to tag you in my previous message - the repo is here.

Thanks.

[jalseth]

+1, unable to use mpv with 780M amdgpu on nixos-stable @ fbca5e745367ae7632731639de5c21f29c8744ed.

[quinnvoker]

I run into the same error trying to run the cinny-desktop package from unstable on a system on the 24.05 branch.

[shymega]

I think, ultimately, the issue comes down to mixing packages from unstable (with a newer version of Mesa), with stable.

One solution would be to override the unstable package's mesa input with stable's mesa package, as previously described in this thread.

[workflow]

Same for unstable.brave to make it searchable, syncing the mesa versions worked!

[ebr]

The fix suggested in https://github.com/signalapp/Signal-Desktop/issues/6855 worked for me on Framework16, which has an integrated AMD Phoenix1 GPU.

export LIBVA_DRIVER_NAME="vdpau"

downgrading or uninstalling mesa-va-drivers did not work. same linked issue suggests this might be also related to ROCm being installed. But I have not uninstalled it to verify.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/cannot-run-chrome-nor-chromium/54373/5

[shymega]

I don't think this is related to libva. The issue was [originally] due to mixing unstable Mesa and stable Mesa.

If people are experiencing the same issue, even when overriding the mesa input, please update the issue. For libva, I believe that is a separate issue.

[Wraaath]

Yeah setting export LIBVA_DRIVER_NAME="vdpau" doesn't fix it for me using MPV unstable.

[le0nAg]

As mentioned in the thread on discourse I'm experiencing the same error on the stable channel that I always used. Is there the possibility that some stable packages where contaminated by some unstable dependencies? Actually this hypothesis it the only one that I have that would explain the issue