That's interesting. I'm no expert on the Steam Deck, but I would have expected it to work. Do you have any more details about the problem?

Valve is using the 'wrong' AMD gpu driver.

That's not enough information for me to understand what's wrong, but I suppose maybe I should find a Steam Deck and try things out myself. If you want to follow up privately, my email is in my profile.

There's actually 3 drivers for vulkan, amdgpu-pro, amdvlk, and radv.

In any case, ROCm works with the completely open source stack, and is open source itself. amdgpu, the kernel component, is the only thing needed for that, and modern upstream works fine. The integrated steam deck gpu simply can't work with it, though.

The issue that has recently been resolved was that only the amdgpu-pro userspace had working OpenCL 2.0+ support. Mesa 22.3 has better OpenCL now, but that's actually become less relevant with the new HIP/ROCm stuff.

> The integrated steam deck gpu simply can't work with [the kernel amdgpu], though.

That's a shame. I was hoping it was something I could help with, but that's a bit beyond the scope of what I can fix myself.

not sure why you added that "[the kernel amdgpu]" bit -- pretty sure that isn't what gp was saying.

the open source kernel driver is the only one in use and sits under both the open source and closed source userland driver stacks.

i'm pretty sure what they're saying is that rocm doesn't support running on the apu in the steam deck at all -- i'm dealing with a similar issue in bringing up a product on a different amd apu that has a beefy enough gpu for my application

If so, that's more promising. The HIP runtime sits on the ROCm Runtime (ROCr), which sits on hsa-kmt (ROCt). I was under the impression that the driver handles pretty much all of the stuff that is hardware-specific.

It's an RDNA2 GPU and AFAIK, all the RDNA2 GPUs can be coerced into working with ROCm (even if they are not 'supported'). Maybe the Steam Deck is an exception. I don't know. I'll give it a spin over the holidays. Win, lose or draw, it sounds like I'll learn something interesting.

I borrowed a friend's Steam Deck and created a Debian userland to check if there were any issues using the hardware for ROCm. As far as I can tell, the only reason ROCm doesn't work on the Steam Deck is that the necessary software has not been packaged for SteamOS yet.

When I check rocminfo, the hardware is reported as gfx1033, which is an identical instruction set to gfx1030, so export HSA_OVERRIDE_GFX_VERSION=10.3.0 should work perfectly if you're using the AMD binaries. Or you can build from source for gfx1033, but that's probably more painful than necessary.

The one catch is that the Steam Deck is currently using Linux 5.13, which predates a lot of bug fixes. I was noticing bugs while using the upstream kernel when packaging ROCm for Debian until something like Linux 5.19. My test case for the Steam Deck was rocRAND, which passed most of its tests. I would expect the rest to pass with a newer kernel, though I haven't verified that.

tl;dr: ROCm is not packaged for easy installation on all the platforms you might want to use it on, but it appears that the hardware works and the software exists.

AMD does have two different drivers (which I find maddening). I bought a monstrous GPU to use for hashcat, but the open source/built-in drivers don't support the openCL that hashcat (and crypto mining) need. The Pro driver doesn't get updated fast enough to work on Fedora, which is also a travesty for me. I really wish that weren't the case.

I can't speak for steam deck though, just my experience on a self build.

Have you heard about just-released Mesa 22.3 which now has rusticl for modern OpenCL support? Previously Mesa used Clover for OpenCL, which was stuck somewhere just below OpenCL 1.2 (but only reports OpenCL 1.1 support).

There are two drivers for AMD on Linux. There's the open source driver, Mesa, and there's the proprietary AMD driver, called AMDGPU. I'm not certain which driver Valve is using on Steam Deck (I've never had to look), but if they're funding Mesa, I'm guessing they're using Mesa.

Unfortunately, some of AMD's GP-compute infrastructure is only supported on Linux through the proprietary driver. I believe these are ROCm and HIP. I'm not sure about OpenCL. I'm not 100% sure what Blender uses for AMD acceleration, but if it's ROCm, you'd need the AMDGPU driver instead of Mesa.

Could have some of these details wrong, but I believe that's the gist of it.

You can, of course, install other OS on the Deck.

this is sorta true, but not quite

amdgpu is the underlying open source kernel module -- it's in the mainline kernel.

mesa is the open source userland driver, and runs atop the amdgpu kernel driver

amdgpu pro is the closed source userland driver, which also runs atop the open amdgpu kernel driver.

what's really nice about this is that you can run a fully open source stack in your host os while running amdgpu pro/rocm inside a container.

I believe they're misrepresenting the issue. Blender's Flatpak is possibly broken, but I'd imagine the Steam Runtime version works without-flaw.