AMD Ryzen 7 Pro APU (2700U / Laptop) - Shared VRAM

Hey Guys,

Does anyone know if it’s possible to override the BIOS set VRAM Buffer? (Usually 256MB or 512MB) in BIOS to something greater?

Also can the kernel read/write to that buffer address?

We are talking laptop here, right?

Yeah sorry, the 2700U Specifically

If you don’t have a setting in BIOS for that I am not sure there is much you can do. Laptops are legendarily restrictive about everything and this is mainly why I don’t like to deal with any.
My initial response is “Most likely nothing you can do about it”.

1 Like

I don’t think it matters too much, the mesa driver usually takes up heaps of system RAM (1-2GB), the 256MB buffer is literally the link to the GPU, I think.

I wonder if AMD have something similar to Intel’s Boot Guard, where it blows a pubkey hash(?) into a fuse array on the CPU, to check BIOS Signatures, if not, should be able to edit the BIOS and open that buffer up.

May I ask why you want to set the allocated VRAM size?
I am reasonably sure, when the APU needs more than the pre allocated amount of RAM, additional space will be allocated to it.

1 Like

The thing with AMD is they are using HSA and whatever it was… Basically they don’t really dedicate specific space in the ram for the GPU. They allow both the CPU and GPU to access the same ram at the same time, so you are saving a lot of time by not moving data from here - there. My point being, I don’t think you even need to allocate more space.

1 Like

Not sure, just want to play, any idea how it dynamically scales? BIOS? It was my understanding the Shared Buffer will always be what the limit is, it’s the driver that scales?

Hmm, so the GPU can access all system memory? :confused: I hope that’s not the case, I was hoping BIOS/UEFI would limit the GPU to the allocated buffer.

Let’s say it can access only 256MB at any given time. But yes, I think it can access all the memory. It basically saves time… It’s a good technology.

1 Like

There was a bit of a controversy with early benchmarking of the Ryzen APUs, my guess is the mobile variant works the same and the graphics portion will use the amount of VRAM it needs:

It only uses what it needs, it is not gone for system use when you boot. In my book it’s a good thing because you won’t hit a performance wall when you run out of allocated VRAM and you can use the not allocated memory when you need it for something else.

Edit: Think the other way around. You can’t ever use the pre allocated portion of your RAM. So when you allocate less you will have more for the rest of the system when the integrated GPU does not need it.

2 Likes

Awesome, cheers for clearing that up!

You’re welcome :slightly_smiling_face:

Also thanks @psycho_666. I didn’t know it was allocated in 256MB chunks. I mean, it makes sense but anyway, good to know.

1 Like

Would you know how to view how much “VRAM” is being used? Running glxinfo shows me

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 620 (Kabylake GT2)  (0x5916)
    Version: 17.0.5
    Accelerated: yes
    Video memory: 3024MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2

Meaning I’m using 3GB

But when I run lspci

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02) (prog-if 00 [VGA controller])
Subsystem: Dell Device 075b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 139
Region 0: Memory at db000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]

It’s 256MB, does this mean the mesa driver is where it’s “spilling” into?

Edit: 2nd Question: Where’s is the “last-hop” for the buffer? What address is the screen actually listening to, to then display it? I would have assumed the 0x90000000 address in lspci.

What? No, that’s just a number I used as an example…

I am not sure this is the actual video memory used, more like what is allocated. Maybe start something graphics heavy and take a look what changes.

I would need to look that up. My guess is, that you are correct in that it has to be transparent to the OS in some way. So, the driver seems like a save bet, but this is not an area where I know enough to be able to say either way.

hmmm … best take a look at the driver docs. Maybe someone comes by that knows what he is doing. Me staring at the code does not seem to help :grin:.

Oh, sorry about that, I misunderstood.

2 Likes

I have a feeling the 256MB Fixed size is literally just the Frame Buffer that the GPU Cores are Reading, you can actually map in Dedicated Video Memory and use it as swap (http://wikigentoo.ksiezyc.pl/TIP_Use_memory_on_video_card_as_swap.htm) for funzies.

I’ve wanted to do this on a VPS I own (Cirrus Drivers) to corrupt the Framebuffer so the console wouldn’t work.