I tried the GPU tutorial but running mojo vector_addition.mojo results in “No compatible GPU found“. I find this odd because I installed the AMD drivers for the GPU that is integrated with the AMD CPU (it’s called an APU). RadeonTop shows the APU working. PyTorch is able to detect the APU via ROCm. Even WebGL is able to make use of the APU. I was really looking forward to learning and using Mojo, but ended up disappointed. I understand it’s hard for y’all to support all GPU’s, and even AMD stopped supplying updates for the APU I have. I only hoped that I would be able to use Mojo with this APU. Looks like I’ll just have to make do with PyTorch…
AMD’s spotty support for APUs makes it difficult for us to support them, which APU is it in particular?
Sorry. I should’ve posted the details:
AMD Cezanne driver: amdgpu v: 5.18.13 bus-ID: 30:00.
Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: amdgpu,ati
unloaded: fbdev,modesetting,vesa gpu: amdgpu resolution: 1600x900~60Hz
OpenGL: renderer: RENOIR (renoir LLVM 15.0.3 DRM 3.48 5.15.0-107-generic)
v: 4.6 Mesa 22.3.0-devel direct render: Yes
CPU:
Info: 6-core model: AMD Ryzen 5 5600G with Radeon Graphics bits: 64
type: MT MCP arch: Zen 3 rev: 0 cache: L1: 384 KiB L2: 3 MiB L3: 16 MiB
System:
Kernel: 5.15.0-107-generic x86_64 bits: 64 compiler: gcc v: 11.4.0
Desktop: Cinnamon 6.0.4 Distro: Linux Mint 21.3 Virginia
base: Ubuntu 22.04 jammy
Machine:
Type: Desktop Mobo: Micro-Star model: B550M PRO-VDH WIFI (MS-7C95) v: 1.0
The 5600G has a Vega GPU, GCN 5, and doesn’t really have support in modern versions of ROCm libraries. Since the driver works, you can try to do bringup, but a lot of weird stuff might happen since Mojo is mostly targeting RDNA/CDNA and it being GCN-based may send you down codepaths intended for CDNA. If you want to take a stab at helping make Vega work, I can give you some pointers, but it is going to be a decent amount of work. Alternatively, quite a few people have expressed a desire for a Vulkan/OpenCL fallback and that may happen once the Mojo compiler goes open source, which would enable some level of support.
Making Vega work with Mojo would effectively be a compiler engineering project. I understand it would involve teaching the Mojo compiler how to translate high level code to the language the chip understands. From what I understand, Mojo turns the code into “Mojo IR” then into “GPU Dialect IR”. When it reaches the final stage, it creates a Code Object that uses the GCN 5 (Vega) instruction set. So I’d need to learn how high-level loops are lowered into GPU kernels, how to configure the AMDGPU Backend for the amdgcn-amd-amdhsa target, understand warps/wavefronts, register pressure, and how Vega’s memory hierarchy differs from newer chips. Even though I’ve worked professionally with C++, it wasn’t hardware-level C++, so it’s not really practical for me to venture into this (and I see why y’all wouldn’t be taking up this, since RDNA/CDNA looks like the way forward, but I still decided to request the ROCm team to continue providing support for the APU since hardware prices skyrocketed). If Vulkan/OpenCL is the way forward, then so be it. Though I believe it’d involve sacrificing some low level performance boost provided by optimizations RDNA/CDNA chips. Thank you for replying.
I think the prominent reason why those GCN based APUs drops the “No compatible GPUs found” on Mojo written kernels is because the GCN framework which has support for MLIR doesn’t explicitly have support for “typed pointers” and most of the MLIR based GPU kernels rely on “bare pointer’s”.
To make it run implementation for bare pointer’s is the only valid method to handle the situation on your APU.
Compiling for Vega already works if you turn it on, it’s mostly filling in the standard library and the kernels that people expect to be present like matmul.
1 Like
@trojan_x Compiling works fine, it’s stdlib support that’s an issue.
Yes I comply with you Owen on the “ Stdlib” support.
That’s because “Mojo doesn’t have a matmul kernel written specifically for the GCN 5 architecture, the “Standard Library” is technically “missing” that support”.
But here is my point “Your libraries won’t work if the compiler handles pointers incorrectly for this ISA.”
Both our points on this Vega support can therefore be marked as the solutions 
.
What’s your view towards this…. I’ll accept any corrections.
@Nav some experiments have shown surprisingly positive results on some later GCN GPUs without any compiler changes. I know @BradLarson has worked on RDNA bringup using just the (already open source) stdlib and kernels repo and plumbing in the targets, so I can try pointing you at some example commits for that side if you want to pick this up!
I don’t want to guarantee it’ll continue to work though, as we are unlikely to test GCN internally for stability and rocm has now deprecated Vega support (including 5.1 from the RVII and Mi50/Mi60). I’m very excited to see these things are possible though, and am still rocking a RVII in one of my machines in the hope it’ll go back to being broadly useful for GPGPU, so don’t be afraid to reach out if you run into any snags trying to work on this!
Our floor for AMD support is that we require at least an AMD driver version of 6.3.3, so if you can install that on your system, there’s a possibility for adding support. On AMD, pretty much all of this functionality is defined at the Mojo standard library and kernels level, all of which are in open source.
Hacking on that doesn’t need compiler expertise, you just need to test on your hardware and see where our checks assume RDNA devices or certain capability level. Adding GCN support might be as simple as adding a few @parameter ifs in the right places, especially since the latest nightly should have fixed the last few places that were CDNA-specific for running MAX models.
1 Like
Thank you Sawyer and Brad. Unfortunately the last working version of ROCm on my hardware is version 5.4.5. Even version 5.5.5 didn’t work. Versions 6 onward definitely do not, and I had to switch back from Linux Mint 22 to Linux Mint 21 just to be able to install version 5.4.5 and use the APU. Others have struggled too as mentioned in this thread and I’ve raised an issue on this page. I guess I’ll have to use some other language/framework for now. The purpose of using Mojo was to try and build an LLM from scratch (a splendid effort by your team), in order to figure out how to alter the architecture of language models (like how Chronos 2 was created) and explore the possibility of building a low-compute agent that generated its own GUI widgets dynamically based on the need, rather than requiring me to program the GUI. Given that there does not appear to be native implementation of graphics, it’s perhaps better to use C++ or PyTorch. I’m grateful for the sincere offers to help, but it looks like unless AMD continues offering support, and until graphics gets a priority for Mojo, it wouldn’t be worth pursuing this line of discussion.
You should double check what happens if you compile ROCm from source. Often times, AMD “dropping support” is them no longer including a target in the build, but everything still functions.
@owenhilyard Thank you. That’s interesting to know…though it’d depend on me figuring out which target to include in the build 
I wouldn’t be trying it right away, but I did have a look at the Git diff between version tags and it might actually be possible to use an AI to figure out what changed that caused the issue.