I installed rocm a couple times, either through the amd-gpu script or the tarball or the new apt repo for ubuntu... with the new rocm versions and the new repos on ubuntu it's unclear if you need to follow the post-install instructions or not, like, the module-list returns No Modulefiles Currently Loaded. with the igpu ubuntu apt install for rocm 7.2 but there's nothing in the instructions that even mention loading a module, do you have to? like... the docs are very unclear....you can... I mean I did load the rocm module but do you need to?
#The "right" way to install on linux **for igpu's**? Do you need to "load" the module or not?
1 messages · Page 1 of 1 (latest)
Post-install link: https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/post-install.html#config-rocm-path
The actual install link: https://rocm.docs.amd.com/projects/radeon-ryzen/en/latest/docs/install/installryz/native_linux/install-package-manager.html
Post-installation instructions
It would be great to clarify because many libraries are not up-to-date for rocm and it sucks to feel like a 2nd class citizen on linux when you're using a brand new ryzen 7 ai igpu with an 880m or 890m.
The new OCR model is great, I've seen it and ran the docker image but it's meant for instinct gpu's with 32gb shim allocated in the init... that's not very lightweight. And the doc to get the faster LLM model is very incomplete - there's not even an explanation how the tutorial goes from processing an image locally to creating a back-end with an exposed port. Doesn't work on igpu's anyway either... Like... Can we just get a bit of love as ryzen users?
Everything feels deprecated and you need to try and fix stuff everytime because the libraries never work, so many memory access errors for migraphx and miopen and the GCC being used instead of the vram.... the latest drivers were a great step-up but there's nothing compatible...
The "right" way to install on linux for igpu's? Do you need to "load" the module or not?
Hi 👋 A lot of topics) Splitting the large problem to small ones and solving them is better approach
Which cpu do you have? I have a HX370 with 890m and have been informed by amd that it's not yet supported in rocm. See: #1467940895658872914 message
I have a ryzen 7 ai pro 360 with an 880M. I know officially the docs only mention the 365 being supported but the 365 has the exact same architecture so I guess it's the same stuff - gfx 1150 yep. Same as me. @pale scarab
It's probably the lack of onnx support that hurts the most in my case personally...
Well, fine. I followed the native install with package manager for rocm 7.2 - should I enable environment-modules or not?
Or just use the export PATH=$PATH:/opt/rocm-7.2.0/bin
it says rock module is loaded in rocminfo now so I guess that solves this... and for ryzen 300 series apu's I hope you guys will actually realize the potential for small servers and laptops, dev, etc...
To get the Radeon 860M/890M running on Ubuntu 25.10, copy and paste this entire block into your terminal. It skips the broken kernel drivers and installs the user-space libraries directly.
bash
1. Update and install prerequisites
sudo apt update && sudo apt install -y wget gnupg2 software-properties-common
2. Add the AMD ROCm GPG key
sudo mkdir --parents --mode=0755 /etc/apt/keyrings
wget https://repo.radeon.com -O - |
gpg --dearmor | sudo tee /etc/apt/keyrings/rocm.gpg > /dev/null
3. Add the ROCm 7.2 repo (using 'noble' for 25.10 compatibility)
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com noble main" |
sudo tee /etc/apt/sources.list.d/rocm.list
4. Set priority and install the SDK
echo -e 'Package: *\nPin: release o=repo.radeon.com\nPin-Priority: 600' |
sudo tee /etc/apt/preferences.d/rocm-pin-600
sudo apt update
sudo apt install -y rocm-hip-sdk rocm-opencl-sdk rocm-libs
5. Configure permissions and library paths
sudo usermod -a -G render,video $USER
echo "/opt/rocm/lib" | sudo tee /etc/ld.so.conf.d/rocm.conf
echo "/opt/rocm/lib64" | sudo tee -a /etc/ld.so.conf.d/rocm.conf
sudo ldconfig
6. Apply hardware overrides to your .bashrc
cat << 'EOF' >> ~/.bashrc
ROCm Overrides for Radeon 800M series iGPUs
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PATH=$PATH:/opt/rocm/bin
EOF
echo -e "\n\033[1;32mInstallation complete! Please REBOOT your computer now.\033[0m"
Use code with caution.
What to do next:
Reboot your machine.
Run rocminfo in a new terminal.
If you get a "memory allocation" error later when running AI models, you may need to increase the UMA Frame Buffer (VRAM) in your BIOS to 8GB or higher.
That's how I got the 860m to work. It's should work for the 890m as well
I run Fedora, although I have tried installing the 7.2 packages directly too, I don't recall if I tried the HSA_OVERRIDE though. My issue is more that there's an internal crash within the gpu drivers when using rocm with a 1024x1024 diffuser size, whilst 512x512 works fine. I'll probably just wait for full support to release and trickle down into the next fedora release then re-test and report a bug if there's still issues. In the mean time I've got a 9700 to install on desktop, at least I do once the bigger PSU arrives.
@hoary thicket HIP maths finally work on my igpu on kernel 6.17 generic hwe for ubuntu with The Rock 7.12 with an env var in my .bashrc setting: export HSA_OVERRIDE_GFX_VERSION=11.5.1
about fkn time I'd say but anyway, gg
@pale scarab look up
by the way I have a 880M
should work with a 860M too
You're much closer to 1150
I know. I have a 1150. But apparently they're giving 1151 more love first... I can always just untar the 1150 version to compare eh but I doubt it would change much.
even when I use the 1150 tar it says I have a 890M lol
test_hip_api works without the gfx_override tho so great news
the latest nightly build dates from the 18 so I guess either they're focussing on windows or they consider the linux version stable
but test_hip_api works without the gfx_override var so thats cool
and vram is reported correctly in amdgpu_top
yay
That's because gfx1150 is Radeon 890M. It is correct.
Idk what 880M is tbh
the 1150 pipeline is fked up anyway
migraph and miopen crash and all
amd devs literally told me to just install 1151
880M is 1150 too, anyway, devs told me to just get the 1151 strix halo build even for strix point apu's..... because the firmware and targets aren't correct for 1150 atm.
and indeed it works
(╯°□°)╯︵ ┻━┻
The problem is that gfx1150 support in ROCm is currently incomplete – the firmware, kernel targets, and library paths (MIOpen, MIGraphX, etc.) are not fully correct yet. That’s why you see crashes and missing kernels.
gfx1151 has the correct kernel implementations and tuning, and it’s much more stable. Using gfx1151 is the correct workaround until fully fixes the gfx1150 pipeline.
Nice. Sad to say though, for ryzen 7 Krackan I switched back to windows. I already did the impossible when AMD dev team told me they don't support NPU inference on the Krackan for Linux, I sent them a picture of benchmarks with a 7b qwen coder grafted to the tiles and 30 custom kernels haha. But the truth is, the ryzen 1.7 setup and onnx genai runtime is faster due to the near non existent documentation for the Krackan NPU. I'll switch back in the future and continue my documentation and such.
Isn't krackan point just strix point with cores disabled?
No, Krackan Point is not a salvaged or binned Strix Point die with fused-off cores. It is a completely distinct, physically smaller monolithic piece of silicon designed from the ground up.
While chipmakers frequently use binning (disabling defective cores on a larger die to sell as a lower-tier SKU), doing so with Strix Point for the mainstream, high-volume market would be cost-prohibitive because of the wasted silicon. Instead, AMD taped out Krackan Point as a leaner, purpose-built die. In short, Krackan is a leaner, single-CCX counterpart to Strix, not a defective hand-me-down.
Zero Cross-CCX Latency: Strix Point splits its 12 cores across two Core Complexes (CCXs)—one containing the four standard Zen 5 cores, and the other housing the eight dense Zen 5c cores. If the OS scheduler bounces a thread between a standard core and a dense core, it incurs a cross-CCX latency penalty and an L3 cache miss. Krackan Point packages all 8 of its cores (both standard and dense) into a single CCX. They all share the same 16MB pool of L3 cache, effectively eliminating cross-CCX communication overhead.
It's all open source, just find one close to your gpu specs and fill in the blanks. Most of it is plug and play with a few trivial parts you have to tweak but it's a lot easier than it looks. I made 30 custom kernels for the ryzen 7 AI silicon to run by just picking apart pieces and stitching them together.
That’s really cool, nice work on those custom kernels.
And a word to anyone out there doing custom work, don't listen to what AMD says about it's not possible or wtv. It is. Especially on Linux because literally everything is open source. They told me the npu handshake on Linux was impossible on a ryzen 7 Krackan point because they don't officially support it, https://github.com/leenoah782-blip/omega2.5-npu-stack
They do now haha.
GitHub
Reference material for Omega 2.5 NPU inference stack — AMD Krackan AIE kernels, Qwen 7B Coder INT4 configs, hardware setup - leenoah782-blip/omega2.5-npu-stack
Thank you. If anyone needs help architecting custom kernels for the GPU, drop me a message with your gpu and hardware info and I'll try to do what I can.
until they fix all the calculations, specially MLIR, not much to do but wait sadly
Trial and error. Just take what you know and what you got and start creating. That's how I got the full handshake on the ryzen 7 350 series. I just started pulling what was general access and adding in the parts to make it work. That's why Linux is beast. Almost everything is open source. And if it isn't there's enough general access knowledge to recreate the missing links.
I can't knock it. IRON AIE and the MLIR tool chain are fantastic for ryzen development on Linux. Thats how I accomplished all the custom work I did.