I looked this up before buying the GPU, and I read that it should “just work” on Debian stable (Bookworm, 12). Well, it doesn’t “just work” for me. :(

clinfo returns two fatal errors:

fatal error: cannot open file '/usr/lib/clc/gfx1100-amdgcn-mesa-mesa3d.bc': No such file or directory

fatal error: cannot open file '/usr/lib/clc/gfx1030-amdgcn-mesa-mesa3d.bc': No such file or directory

I get similar errors when trying to run OpenCL-based programs.

I’m running a backported kernel, 6.6.13, and the latest Bookworm-supported mesa-opencl-icd, 22.3.6. From what I’ve found online, this should work, though Mesa 23.x is recommended. Is it safe/sane to install Mesa from Debian Trixie (testing)?

I’ve also seen references to AMD’s official proprietary drivers. They do not officially support Debian, but can/should I run the Ubuntu installer anyway?

I’m hoping to get this up and running without any drastic measures like distro hopping. That said, if “upgrade to Testing or Unstable” is the simplest approach, I am willing to entertain the idea.

Thanks in advance for any help you can offer.

    • @hershOP
      2•12 days ago

      Ah, somehow I didn’t see 18 there and only looked at 17. Thanks!

      I tried pulling just the one package from the sid repo, but that created a cascade of dependencies, including all of llvm. I was able to get those files installed but not able to get clinfo to succeed. I also tried installing llvm-19 from the repo at https://apt.llvm.org/, with similar results. clinfo didn’t throw the fatal errors anymore, but it didn’t work, either. It still reported Number of devices 0 and OpenCL-based tools crashed anyway. Not with the same error, but with something generic about not finding a device or possibly having corrupt drivers.

      Should I bite the bullet and do a full ugprade to sid, or is there some way to this more precisely that won’t muck up Bookworm?

      • @hershOP
        3•12 days ago

        Update: I upgraded to Sid. Unfortunately, mesa-opencl-icd depends on libclc-17, which uninstalls -18. So I can’t get OpenCL working while the correct libclc is installed.

        No idea where to go from here. I’ll probably restore my Bookworm snapshot, since I don’t want to be on Sid if it doesn’t solve this problem.

        • @bloodfart@lemmy.ml
          3•12 days ago

          you ought to be able to specify the version to install of libclc after mesa-opencl-icd is installed, you could instead force the newer libclc 18 with dpkg. you can also create a vile mutant install by adding sid backports or repository to your perfectly fine stable install. here are some resources to help you destroy your system

          e: i was hoping that last sentence would be clearly four links because of underlining but that’s not working, here it is in cursed haiku format:

          here are

          some resources

          to help you

          destroy your system

          • @hershOP
            2•11 days ago

            IT WORKS NOW! I will need time to run additional tests, but the gist of my solution was:

            1. Backport llvm-18 from sid following the guide you linked at https://wiki.debian.org/SimpleBackportCreation

            2. After compiling and installing all those deb files, I then installed the “jammy” version of amdgpu-install_6.0.60002-1.deb from https://www.amd.com/en/support/linux-drivers

            3. Downloaded the latest kernel sources from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, and simply copied all the files from its lib/firmware/amdgpu folder into my system’s /lib/firmware/amdgpu. Got that idea from https://discussion.fedoraproject.org/t/amdgpu-doesnt-seem-to-function-with-navi-31-rx-7900-xtx/72647

            4. sudo update-initramfs -u && sudo reboot

            I’m not totally sure it step 3 was sane or necessary. Perhaps the missing piece before that was that I needed to manually update my initramfs? I’ve tried like a million things at this point and my system is dirty, so I will probably roll back to my snapshot from before all of this and attempt to re-do it with the minimal steps, when I have time.

            Anyway, I was able to run a real-world OpenCL benchmark, and it’s crazy-fast compared to my old GTX 1080. Actually a bigger difference than I expected. Like 6x.

            THANKS FOR THE HELP!

          • @hershOP
            1•11 days ago

            Thanks for the links! I’ve never attempted making my own backport before. I’ll give it a shot. I might also try re-upgrading to sid to see if I can wrangle it a little differently. Maybe I don’t actually need mesa-opencl-ics if I’m installing AMD’s installer afterwards anyway. At least, I found something to that effect in a different but similar discussion.

  • @Shareni@programming.dev
    3•13 days ago

    I don’t have an AMD card, so it’s better to wait for more informed advice, but in the meantime try the following

    1. ls /usr/lib/clc | grep gfx to verify it’s actually installed
    2. If not installed sudo apt-get install --reinstall mesa-opencl-icd
    3. If not fixed, create a snapshot and try to install the Ubuntu rocm
    • @hershOP
      4•13 days ago

      Thanks, that’s good advice. There are lower-numbered gfx* files in there. 900, 902, 904, 906. No 1030 or 1100. Same after reinstalling.

      Looks like these files are actually provided by the libclc-15 package. libclc-16 has the same set of files. Even libclc-17 from sid has the same files. So I guess upgrading to testing/unstable wouldn’t help.

      apt-file search gfx1100-amdgcn-mesa-mesa3d.bc yields no results, so I guess I need to go outside of the Debian repos. I’ll try the AMD package tonight.

      • @hershOP
        2•12 days ago

        Update: Running amdgpu-install did not provide those files. There were a few errors regarding vulkan packages when I attempted, I guess because it’s assuming Ubuntu repos. Trying with just opencl and not vulkan succeded, but still clinfo reported the missing files.

        I don’t think I can get this working without a whole newer llvm.

  • Possibly linuxEnglish
    1•12 days ago

    Debian likely has to old of a kernel. Maybe you could try installing a more recent version from backports or switching to Fedora.

  • @TerraRoot@sh.itjust.works
    1•13 days ago

    I’m still running rx570, so I’m no real help, but +1 for using debian testing, been daily driving it for years on my gaming desktop. stable for server’s and hardware that isn’t booted up daily.

    • @Shareni@programming.dev
      0•13 days ago

      for using debian testing, been daily driving it for years on my gaming desktop. stable for server’s and hardware that isn’t booted up daily.

      Why even use debian at that point?

      Half of all of my packages are from nix unstable, but the system itself is still debian stable. That means I’ve got the bleeding edge user packages, but my system always boots. Casuals can use flatpak instead.

      The only downside is for bleeding edge hardware, but again, why use debian at that point.

      • @TerraRoot@sh.itjust.works
        4•13 days ago

        Because I’ve been using an apt-get based distro since the late 90’s, Because I work in IT, Because I don’t like rice/hours of config/features. Yawning chasm of difference between always boots and always boots and dive right into work/game/browsing/whatev’s

      • @hershOP
        1•12 days ago

        Can you explain more about your workflow? Do the Nix packages have their own isolated dependency resolution? How does it work when Debian packages depend on a library you get from Nix, or vice-versa?

        • @Shareni@programming.dev
          2•12 days ago

          Can you explain more about your workflow?

          Here’s an example. The main difference to my current setup is that I’m installing nixGL through nix-channels because then I don’t have to use --impure that way, although I still haven’t gotten around to automating its usage so that might still change.

          Basically I just have list of packages that I want installed (home.nix), and I run updates a couple of times a week. If something breaks (it hasn’t yet), I could just roll back to a previous generation.

          Do the Nix packages have their own isolated dependency resolution?

          Each package has specified dependencies, nix downloads them separately and then symlinks them in order for the package to access it. If two packages require the same version of the dependency, based on the hash of the output, they’ll each get a symlink of the same dependency. If they require different versions, it will download the correct ones for each of the packages.

          That way you’re theoretically never get mismatched dependencies, but it uses a bit more space.