github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #11451] GPU not detected on Ryzen AI 300 (gfx1150) with Dynamic VRAM, but works with Fixed VRAM #54074

New Issue
Closed
opened 2026-04-29 05:11:06 -05:00 by GiteaMirror · 10 comments
GiteaMirror commented 2026-04-29 05:11:06 -05:00
Owner
Copy Link

Originally created by @Billionatoms on GitHub (Jul 16, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/11451

System Information:

  • Host: Framework Laptop 13 (AMD Ryzen AI 300 Series)
  • CPU: AMD Ryzen AI 9 HX 370
  • GPU: AMD Radeon 890M Graphics (gfx1150)
  • OS: Arch Linux
  • Kernel: 6.16.0-rc6-1-mainline (also tested on stable kernel 6.15.6)
  • Ollama Version: 0.9.6 (or newer)

Describe the bug
On systems with the new Ryzen AI 300 series APUs (gfx1150), Ollama's behavior depends entirely on the UEFI/BIOS setting for graphics memory.

  • When UMA is set to "Auto" (Dynamic VRAM): Ollama fails to detect the GPU and falls back to CPU mode. The service log shows the error: error="amdgpu version file missing: /sys/module/amdgpu/version"
  • When UMA is set to a fixed size (e.g., 32GB): Ollama correctly detects and uses the GPU for inference, even though the /sys/module/amdgpu/version file is still missing.

This indicates that the strict check for the version file is only problematic when the GPU is in its recommended dynamic memory mode. When a large, fixed VRAM is presented, the ROCm stack initializes successfully despite the missing file.

To Reproduce

  1. Use a system with an AMD Ryzen AI 9 HX 370 APU on a modern Linux kernel.
  2. In the UEFI/BIOS, set the graphics memory to "UMA Auto".
  3. Ensure the ollama service is configured to use the HSA_OVERRIDE_GFX_VERSION=11.0.0 environment variable.
  4. Start the ollama.service and observe that it falls back to CPU mode, citing the "amdgpu version file missing" error.
  5. Reboot, enter the UEFI/BIOS, and set the graphics memory to a fixed size (e.g., 16GB or 32GB).
  6. Start the ollama.service again and observe that it now successfully uses the GPU (library=rocm).

Expected behavior
Ollama should be able to use the GPU when the system is configured with the recommended "UMA Auto" (dynamic) memory setting.
When the HSA_OVERRIDE_GFX_VERSION variable is set, it would be ideal for Ollama to bypass the strict check for the /sys/module/amdgpu/version file, regardless of the memory allocation mode. This would allow for proper GPU acceleration on new hardware without forcing users to select an inefficient fixed VRAM configuration.

Additional context
This behavior is consistent on both stable and mainline kernels. The core issue seems to be that Ollama's initial driver verification fails only in the dynamic memory allocation scenario, which is the default and preferred mode for modern APUs.

Originally created by @Billionatoms on GitHub (Jul 16, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/11451 **System Information:** * **Host:** Framework Laptop 13 (AMD Ryzen AI 300 Series) * **CPU:** AMD Ryzen AI 9 HX 370 * **GPU:** AMD Radeon 890M Graphics (gfx1150) * **OS:** Arch Linux * **Kernel:** 6.16.0-rc6-1-mainline (also tested on stable kernel 6.15.6) * **Ollama Version:** 0.9.6 (or newer) Describe the bug On systems with the new Ryzen AI 300 series APUs (gfx1150), Ollama's behavior depends entirely on the UEFI/BIOS setting for graphics memory. * **When UMA is set to "Auto" (Dynamic VRAM):** Ollama fails to detect the GPU and falls back to CPU mode. The service log shows the error: error="amdgpu version file missing: /sys/module/amdgpu/version" * **When UMA is set to a fixed size (e.g., 32GB):** Ollama correctly detects and uses the GPU for inference, even though the /sys/module/amdgpu/version file is still missing. This indicates that the strict check for the version file is only problematic when the GPU is in its recommended dynamic memory mode. When a large, fixed VRAM is presented, the ROCm stack initializes successfully despite the missing file. **To Reproduce** 1. Use a system with an AMD Ryzen AI 9 HX 370 APU on a modern Linux kernel. 2. In the UEFI/BIOS, set the graphics memory to "UMA Auto". 3. Ensure the ollama service is configured to use the HSA\_OVERRIDE\_GFX\_VERSION=11.0.0 environment variable. 4. Start the ollama.service and observe that it falls back to CPU mode, citing the "amdgpu version file missing" error. 5. Reboot, enter the UEFI/BIOS, and set the graphics memory to a fixed size (e.g., 16GB or 32GB). 6. Start the ollama.service again and observe that it now successfully uses the GPU (library=rocm). Expected behavior Ollama should be able to use the GPU when the system is configured with the recommended "UMA Auto" (dynamic) memory setting. When the HSA\_OVERRIDE\_GFX\_VERSION variable is set, it would be ideal for Ollama to bypass the strict check for the /sys/module/amdgpu/version file, regardless of the memory allocation mode. This would allow for proper GPU acceleration on new hardware without forcing users to select an inefficient fixed VRAM configuration. Additional context This behavior is consistent on both stable and mainline kernels. The core issue seems to be that Ollama's initial driver verification fails only in the dynamic memory allocation scenario, which is the default and preferred mode for modern APUs.
GiteaMirror added the feature request label 2026-04-29 05:11:06 -05:00
GiteaMirror commented 2026-04-29 05:11:09 -05:00
Author
Owner
Copy Link

@mlaihk commented on GitHub (Jul 21, 2025):

Second to this!
And I would go slightly further as to introduce an additional Ollama specific environment variable to specific max RAM to use in shared memory situation so that it can work similarly as a GPU with a set VRAM........

<!-- gh-comment-id:3095125341 --> @mlaihk commented on GitHub (Jul 21, 2025): Second to this! And I would go slightly further as to introduce an additional Ollama specific environment variable to specific max RAM to use in shared memory situation so that it can work similarly as a GPU with a set VRAM........
GiteaMirror commented 2026-04-29 05:11:10 -05:00
Author
Owner
Copy Link

@phush0 commented on GitHub (Jul 21, 2025):

I think it is ROCm problem and not Ollama's, because ROCm can not use GTT memory. I am with Ryzen AI MAX+ and have same problem, and after some search this is my conclusion.

edit: probably I am wrong https://blog.hjc.im/strix-halo-local-llm.html
edit2: problem is with ollama, it is not detecting GTT correctly and disables GPU code

<!-- gh-comment-id:3095184274 --> @phush0 commented on GitHub (Jul 21, 2025): I think it is ROCm problem and not Ollama's, because ROCm can not use GTT memory. I am with Ryzen AI MAX+ and have same problem, and after some search this is my conclusion. edit: probably I am wrong [https://blog.hjc.im/strix-halo-local-llm.html](https://blog.hjc.im/strix-halo-local-llm.html) edit2: problem is with ollama, it is not detecting GTT correctly and disables GPU code
GiteaMirror commented 2026-04-29 05:11:10 -05:00
Author
Owner
Copy Link

@fengwang commented on GitHub (Jul 24, 2025):

This is fatal for amd iGPU devices. Please consider hot fix with something such as a customize environment variable, before detecting the GTT correctly.

<!-- gh-comment-id:3113125320 --> @fengwang commented on GitHub (Jul 24, 2025): This is fatal for amd iGPU devices. Please consider hot fix with something such as a customize environment variable, before detecting the GTT correctly.
GiteaMirror commented 2026-04-29 05:11:10 -05:00
Author
Owner
Copy Link

@MatthK commented on GitHub (Aug 30, 2025):

Is there any update on this? I just got the new AMD RYZEN AI MAX+395 w/Radeon 80605 and I have the same problem that the GPU is not detected with dynamic VRAM.

<!-- gh-comment-id:3238886317 --> @MatthK commented on GitHub (Aug 30, 2025): Is there any update on this? I just got the new AMD RYZEN AI MAX+395 w/Radeon 80605 and I have the same problem that the GPU is not detected with dynamic VRAM.
GiteaMirror commented 2026-04-29 05:11:11 -05:00
Author
Owner
Copy Link

@RobertoMaurizzi commented on GitHub (Oct 4, 2025):

It's apparently a bug in the amdgpu driver, that got fixed only a few days ago in the kernel version 6.16.9+, see: https://github.com/ROCm/ROCm/issues/5444

<!-- gh-comment-id:3367991773 --> @RobertoMaurizzi commented on GitHub (Oct 4, 2025): It's apparently a bug in the amdgpu driver, that got fixed only a few days ago in the kernel version 6.16.9+, see: https://github.com/ROCm/ROCm/issues/5444
GiteaMirror commented 2026-04-29 05:11:11 -05:00
Author
Owner
Copy Link

@maurerle commented on GitHub (Oct 12, 2025):

I have a AMD Ryzen AI 9 365 w/ Radeon 880M runnin debian trixie with backport kernel:
sudo apt install -t trixie-backports linux-image-amd64 linux-headers-amd64
so running 6.16.3+deb13-amd64 kernel.

My GPU was not detected at all and I could not see anything with:

OLLAMA_DEBUG="1"
AMD_LOG_LEVEL=3

Adding HSA_OVERRIDE_GFX_VERSION=11.0.0 fixed this.
Nothing else was required.

I now get: msg="inference compute" id=0 library=ROCm compute=gfx1100 name=ROCm0 description="AMD Radeon Graphics" libdirs=ollama,rocm driver=60342.13 pci_id=65:00.0 type=iGPU total="31.0 GiB" available="30.8 GiB - allowing 50% of my RAM to be utilized from the GPU - without a fixed UMA size.

From the version numbering, it should work with HSA_OVERRIDE_GFX_VERSION=11.5.0 for gfx1150.. Though I do not have such a device.

<!-- gh-comment-id:3395271433 --> @maurerle commented on GitHub (Oct 12, 2025): I have a AMD Ryzen AI 9 365 w/ Radeon 880M runnin debian trixie with backport kernel: `sudo apt install -t trixie-backports linux-image-amd64 linux-headers-amd64` so running `6.16.3+deb13-amd64` kernel. My GPU was not detected at all and I could not see anything with: ``` OLLAMA_DEBUG="1" AMD_LOG_LEVEL=3 ``` Adding `HSA_OVERRIDE_GFX_VERSION=11.0.0` fixed this. Nothing else was required. I now get: `msg="inference compute" id=0 library=ROCm compute=gfx1100 name=ROCm0 description="AMD Radeon Graphics" libdirs=ollama,rocm driver=60342.13 pci_id=65:00.0 type=iGPU total="31.0 GiB" available="30.8 GiB` - allowing 50% of my RAM to be utilized from the GPU - without a fixed UMA size. From the version numbering, it should work with `HSA_OVERRIDE_GFX_VERSION=11.5.0` for gfx1150.. Though I do not have such a device.
GiteaMirror commented 2026-04-29 05:11:12 -05:00
Author
Owner
Copy Link

@dhiltgen commented on GitHub (Mar 11, 2026):

Release 0.17.8 updates Linux to ROCm v7 which covers support for this GPU. Please give the RC a try and let us know if you run into any problems.

<!-- gh-comment-id:4041980553 --> @dhiltgen commented on GitHub (Mar 11, 2026): Release 0.17.8 updates Linux to ROCm v7 which covers support for this GPU. Please give the [RC a try](https://github.com/ollama/ollama/blob/main/docs/linux.mdx#installing-specific-versions) and let us know if you run into any problems.
GiteaMirror commented 2026-04-29 05:11:12 -05:00
Author
Owner
Copy Link

@maurerle commented on GitHub (Mar 11, 2026):

Thanks - works well!

I successfully downloaded the rc using: https://ollama.com/download/ollama-linux-amd64-rocm.tar.zst?version=0.17.8-rc1 and https://ollama.com/download/ollama-linux-amd64.tar.zst?version=0.17.8-rc1 with the manual instructions.

For manual installation I needed an adjustment for zstd -d in the install instructions, see: https://github.com/ollama/ollama/pull/14036/changes

Is there some way to get SHA256 checksums for the versions somewhere?

<!-- gh-comment-id:4042244799 --> @maurerle commented on GitHub (Mar 11, 2026): Thanks - works well! I successfully downloaded the rc using: `https://ollama.com/download/ollama-linux-amd64-rocm.tar.zst?version=0.17.8-rc1` and `https://ollama.com/download/ollama-linux-amd64.tar.zst?version=0.17.8-rc1` with the manual instructions. For manual installation I needed an adjustment for `zstd -d` in the install instructions, see: https://github.com/ollama/ollama/pull/14036/changes Is there some way to get SHA256 checksums for the versions somewhere?
GiteaMirror commented 2026-04-29 05:11:13 -05:00
Author
Owner
Copy Link

@dhiltgen commented on GitHub (Mar 11, 2026):

We publish them with every github release https://github.com/ollama/ollama/releases/download/v0.17.8-rc1/sha256sum.txt

<!-- gh-comment-id:4042491859 --> @dhiltgen commented on GitHub (Mar 11, 2026): We publish them with every github release https://github.com/ollama/ollama/releases/download/v0.17.8-rc1/sha256sum.txt
GiteaMirror commented 2026-04-29 05:11:14 -05:00
Author
Owner
Copy Link

@ddigiorg commented on GitHub (Mar 13, 2026):

Can confirm release 0.17.8 fixes this issue on my Framework (AMD Ryzen AI 9 HX 370) on Arch Linux.

<!-- gh-comment-id:4051703331 --> @ddigiorg commented on GitHub (Mar 13, 2026): Can confirm release 0.17.8 fixes this issue on my Framework (AMD Ryzen AI 9 HX 370) on Arch Linux.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#54074
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?