Ryzen igpu UMA carveout, VRAM allocation on linux, finally found how to change it
Posted by Olwaht@reddit | linux | View on Reddit | 6 comments
so I have an HP OmniBook X Flip 14 (Ryzen AI 7 350, Radeon 860M 24ram/1tb). when I was still on Windows I used to change the UMA carveout directly in AMD Adrenalin, Then as planned for that laptop, I switched to Linux (arch btw) and realized there's just no option to change it anymore. the HP BIOS doesn't have a setting for iGPU VRAM at all and as i understand a lot of laptops with this APU have the same problem, it's completely hidden.
I started looking for ways to fix it. Smokeless UMAF can actually find the hidden AMD CBS settings in the BIOS, but HP uses Insyde H2O so UMAF can read everything but can't save anything. every other tool people recommend hits the same wall. the only remaining options were finding a way to boot Windows again and use Adrenalin, that not sounded fun.
Kernel 7.0 added some new sysfs files for AMD APUs specifically for UMA carveout. So i checked if its here on my machine
ls /sys/class/drm/card*/device/uma/
It was here, genuinely didn't expect that after 2-3 months of trying and using this laptop
cat /sys/class/drm/card1/device/uma/carveout_options
cat /sys/class/drm/card1/device/uma/carveout
Mine showed: 0: Minimum (512 MB) 1: (1 GB) 2: (2 GB) 3: (4 GB) 4: (6 GB) 5: Medium (8 GB) 6: (12 GB), and confirmed I was sitting at index 0 (512MB). so I just did:
echo 5 | sudo tee /sys/class/drm/card1/device/uma/carveout
reboot
After reboot i'm back to 8GB, finaly
Then i changed gtt memory settings so i dont use so much of so called shared memory bc i don't need it anymore
As far as i find, its related to Atom ROM. if your BIOS doesn't expose ATCS the /uma/ directory simply won't be there, so there's no harm in checking.
Posting this because I couldn't find anyone talking about it and spent way too long thinking I needed Windows for this. if you're on any AMD APU laptop and you've been stuck fighting with BIOS restrictions for this, just check if the directory exists. might save you a lot of pain
natermer@reddit
I donno. I thought that Linux handled this properly a lot better then Windows did. That 'UMA carveout' was a hack for Windows to make up for the fact that it really kinda sucked at the unified memory stuff. Same thing with BIOS settings. You don't want to use those with Linux.
At least that was my understanding.
For example I have a Framework laptop with Ryzen AI 9 HX 370. This has Radeon 890M iGPU. I also have a eGPU attached when I am at my desktop. There is 64GB of RAM in the system with 16GB of VRAM in the eGPU.
in "Mission Center" it says for that for my 890M I have "512MiB memory" and "31.0 GiB of shared memory".
I haven't had any issues running LLMs on there using Llama.cpp's Vulkan backend. I have to specify '--device Vulkan0,Vulkan1' to use both of them. I can use either or both of them simultaneously. And I definitely can run 17GB or 24GB models on the iGPU by itself just fine.
It isn't very fast... but I can also tell that it isn't using CPU backend because the CPU usage would be flat. So I know the GPU usage is real.
I am not a expert at this GPU stuff by any stretch of the imagination. So I might be missing the significance of a 'UMA carveout', but the way things seem to be is that I really don't have to care or know while I am using Linux.
Niwrats@reddit
if this is the same setting as the UMA buffer size or whatever the BIOS calls it, then for an igpu use case increasing it can have massive performance improvements on linux (wine). still, even a 60% or whatever i saw improvement is not enough to make more modern games playable on slower igpus.
but if someone is stuck on an igpu system, they should check it out.
Olwaht@reddit (OP)
Yeah, it’s the same setting, it writes changes to bios, so if laptop has only Igpu like in mine, it’s changing performance a lot, when I bought this laptop I selected 24ram because of 16 it’s enough, and 8 “vram” will be ok for any software I need
Olwaht@reddit (OP)
I’m not expert too, but as far as I understand it’s more about allocation policy, memory patterns and how the software using memory, when I personally tested in comfy ui gtt shared memory was working slower, and in games 30-40% less fps So when memory was was allocated, it’s faster in all my cases
BackgroundSky1594@reddit
The only real difference is driver overhead. Setting the value in firmware masks off some of the memory so it's "hardware reserved" and lets the GPU manage it directly without having to worry about what might be allocated where.
The gtt shared memory is managed by the kernel and thus subject to it's memory allocation policies and there's some overhead in that.
With that said, the impact I've observed on my Strix Halo Laptop was MUCH smaller, well under 10% even in games, so I've just set it to automatic (which is the same as 512M) and rely on GTT to handle everything.
It works on the steam deck, it works on basically every Intel iGPU ever, and it works decently well for my AMD hardware too.
Olwaht@reddit (OP)
Yes, I think it’s about strict halo bandwidth, but you know even 10% it’s may be good, in my case it’s 30+, and you know, when such a difference it worth trying)