Support AMDGPU on Raspberry Pi 5 #4159
Conversation
There was a problem hiding this comment.
In my view these changes are too invasive (e.g. AMDGPU driver and firmwares will cause unnecessary bloat for most of the users) given how niche use case this covers, so my call is not to accept these changes here.
For better news, in the past we have discussed how we could make OS forks maintainable more easily - both for developers and for the users, as now your only option to upgrade a forked build is to do that manually from command line or using the offline upgrade with a RAUC upgrade file. As we're also moving away from Supervised installs, we should start looking into this rather soon.
|
Is there a way to add these dependencies to this specific board only that would make it acceptabel? Indeed better ways to maintain these changes externally would be greatly appreciated. My current solution is a custom addon that interfaces with rauc. That means that pretty much updating the addon means updating the OS. But it's a bit confusing to users, so if I could hook into the version JSON that would be much better. |
|
Talking about forks, is there a sanctioned way to preconfigure certain addons and integrations? |
This PR makes it possible to plug an AMD GPU into a Raspberry Pi 5 and run llama.cpp directly on the pi for completely integrated local LLMs.
I'm marking this as a draft to open a discussion about what would be an acceptable way to upstream these changes.
What makes up this PR:
and tangentially related, some changes related to my CM5 GPU board Sentinel Core that definitely won't fly as is:
But maybe these would be acceptable as a new board definition? Some of the other changes could maybe also be scoped to this board?