Memory Split Does What? Increase or leave alone?

Capeman

@thewinterdojer Wait, are we talking about the memory split in the raspi-config or the one that is internal to ES on the UI settings menu? I believe those are different. We might be on different pages. I was referring to the raspberry pi setting, i've read elsewhere that on the ES side, you set it down low.... but who knows, this is all kind of confusing, haha.

theWinterDojer

@capeman I don't even know now haha. I was talking about setting total_mem or gpu_mem in /boot/config.txt

Capeman

I found this on another topic when searching the same issue a few minutes ago regarding the ES setting specifically.

@pjft said in What are all the effects of changing VRAM?:

@NastyButtler322 not quite. To the best of my recollection from reading through that code for quite a while a few months ago, what's implemented in ES is a setting that sets a threshold of memory.
When that threshold is crossed, it will explicitly unload textures from memory in order to load new ones. I'm not sure it's as much VRAM in the normal sense of the word as it is a ES texture memory manager, though I can't say for sure as I didn't implement it.
That's why I have a suspicion that keeping it to high is as bad as having it too low, though I haven't been able to get anyone to test that. Too low means it won't have enough memory reserved to render all it needs to. Too high (I believe) will result in white screens if your Pi runs out of memory before the threshold is hit, as it won't unload textures to load new ones.
Edit: see VRAM mention here:
https://github.com/pjft/EmulationStation/blob/master/es-core/src/resources/TextureDataManager.cpp
The method to unload VRAM just deletes the texture from the GL texture manager. The method to remove from RAM deletes the actual texture data from memory.
https://github.com/pjft/EmulationStation/blob/master/es-core/src/resources/TextureData.cpp

The actual ram split in the rapsberry pi config.txt should probably be left at the default 256 (or the auto split settings that are present), though i usually raise it up 320 without any negative effect (i should probably lower it back down). Setting that setting as low as 80 might mess with the video rendering performance of the pi unit.

theWinterDojer

@capeman Okay, I confused myself. Yes the Vram_limit in the ES menu is what I was referring to being set at 80.

320 should be fine for the memory split, but I don't know what the advantages are from setting it to that.

Also, thanks, I guess I will edit my comment.

Edit:

Setting that setting as low as 80 might mess with the video rendering performance of the pi unit

@pjft Could you possibly provide some clarification on VRAM and memory split?

pjft

@thewinterdojer sure. On my phone right now, but I'll happily elaborate more tomorrow when on my laptop.

The summary is:

memory split: system setting that declares how much memory the system should pre-allocate to GPU/video processing (graphics, rendering, textures, images) vs CPU usable memory (applications, processes, everything else). The pi 1 had it at 128MB I believe. I wouldn't go lower than that. You may go higher but you're pretty much reducing the available memory for actually running the emulators, ES, etc.
VRAM in ES is the threshold at which ES will unload textures from video memory to load new ones, so it doesn't run out of memory. If it's higher than the available GPU memory, you will eventually run out of memory in ES depending on the themes and systems you're running, as it won't know when to stop. If it's too low, it may end up not being able to fully load the needed resources to render the current screen. So it's a balance. I find 80 to be a good sweet spot. This is only for ES.

Hope this clarifies.

theWinterDojer

@pjft

It does help very much, I appreciate your knowledge as always. So in the scenario of increasing the performance of a theme that is sluggish in transitions. Increasing the memory split would be more beneficial then increasing the VRAM limit?

pjft

@thewinterdojer Well... perhaps. It depends.

I don't see, at first glance, where increasing the memory split would hurt the ES performance, as unless you have an enormous collection (and even so), the memory consumption isn's off the charts. EDIT: Unless you increase it so much that ES doesn't have any memory to run on. Unlikely, but a possibility nonetheless.

So you could consider that, and then increasing VRAM to accommodate for that increase.

However, you'd be losing memory for running the actual emulators and such, be mindful of that.

Of course, a theme being sluggish might have several other reasons for it. Remember that the Pi isn't an especially powerful device - we take things for granted these days, but it's important to keep that perspective.

If a theme is sluggish, other things that can be responsible for it can be:

The theme using images/backgrounds/icons at very high resolutions (720p is usually the sweet spot). The Pi needs to load these from the card, load them to video memory, and then render them. Higher resolutions means more memory being used, more time needed to load each image/change images when scrolling, etc.
Same goes for your scraped metadata - thumbnails, marquees, images, videos, etc. All of their resolutions will impact this.

The bottleneck for theme navigation is usually loading all the required metadata resources when changing the selected game (so image, video and/or marquee), and balancing that with keeping the background theme textures (system background, system logo, any additional extras) in memory, and rendering them all each frame. If you're navigating on the system view, or between systems in the Gamelist view, it'll be loading the required resources for the new system view - new background (even if it is the same file, it is a separate texture in memory), new system logo, new icon, and then new selected game on top of that.

Maybe the memory card (or USB drive, depending on what's causing the sluggishness) itself can be the bottleneck there.

There are a lot of potential failure points.

If you want to capture a video of that "sluggishness", I'm happy to attempt an extremely uninformed guess as to what might be happening and whatnot, and what you may test out to improve the performance. No promises that it'll improve anything, though :)

Best.

dankcushions

@retrofreak89 said in Memory Split Does What? Increase or leave alone?:

Good evening!!

I was looking at the settings of the pi
Maybe i can tweak it a little bit without overclocking and i saw this setting called memory split..
I looked it up on the retropie site but i still dont get what it does and what setting is best for it?
Its currently at 256 should i increase or leave it ?whats it do?
Any other settings to look at and change for better performance?
Id like to set this up as tweaked as possible without OC

the retropie site is quite clear on this: https://github.com/RetroPie/RetroPie-Setup/wiki/Memory-Split

there is no benefit to raising the video memory split.

gaavoid

What is the default memory split? I'm not at home to check but I believe my build has it set to 400 and I don't remember ever changing it. I built it from the official prebuilt 4.1 image and have updated a few times since. It's possible I did change it to help with the white screen issues from back then.

BuZz

@gaavoid 128MB for 256MB ram machines, and 256MB for others.

gaavoid

@buzz Thanks. I must have changed it a long time ago to deal with emulation station at the time, then blanked it from my mind. I'll change it back to 256 when I'm back home.
Would me having it set to 400 cause any emulation issues? I've noticed some music stutter/low frame rate on a few FBA roms but put it down to hardware capabilities. Perhaps changing the memory split back to default will change this. I'll report back in a couple of days.

BuZz

@gaavoid Probably not but I don't think 400MB will benefit anything now. Used to be needed for some ES themes before.

theWinterDojer

@pjft

Thank you for the information, I don't want to interfere with any of my emulators so I'm going to leave it alone and bring my background image down from 1080p to 720p and see if that helps. It's only slow on the carousel transition between systems, seems to stutter a little bit. I'm using lilbud's Modern TV theme (I think it's lilbud's at least).

I do not have screen capture set up and I'm leaving for a trip to New York tonight for the week but I will try and get a video when I can. If you don't mind watching a YouTube clip from my phone I'd be happy to upload that.

pjft

@thewinterdojer that works for me, if you're under the impression your background images are 1080p, I'd certainly start there.

Safe trip.

RetroFreak89

@thewinterdojer how do i do this??

akafox

Here is my take..

As far as needing any kind of graphical power not much is needed. Old MAME games (1979-1995) and other 8 and 16-bit emulators don't really use the GPU at all. Retroarch does use it for shaders and filterers and some rendering so you want more GPU for that. But normally the more RAM the CPU has the better.

However...as you get into the more 3-D gaming you need more GPU it is much more demanding to render the objects. Some PSX and ALL of the N64 and Sega Saturn and Sega Dreamcast are GPU hungry.

Problem is they are also more CPU and RAM intensive. There is more [numbers/code] for the computer to crunch and process. So while you might give more RAM to the GPU for rendering you take more from the CPU..and visa versa.

it boils down to the GPU on the PI can only use up to one Gigabyte of RAM max. Now if they could give us two gigs (one for the GPU and one for the CPU) that would be wonderful..but it would also make the PI more expensive. Although a use off DDR3 ram compared to the Rasp PI's DDR1 ram would help performance even if it is still the same amount (one gigabyte)...but then cost again.

When you want better performance with an emulator use a lower resolution. Everybody s about 1080p and HD and all that. Remember though that most of these ran at less than 720p. Yeah it may look like crap but..that is what they looked like lol

When I use the scraper and have it convert the videos down for the pi. It converts 640x480@60fps down to 320x240@30fps they run much smoother and there are no "hiccups" (or at least very few) then with high resolutions video snaps in emulation station.

dankcushions

@akafox you can measure the GPU ram usage in realtime: https://www.raspberrypi.org/forums/viewtopic.php?t=23185

even with n64 and dreamcast, the emulators in retropie don't use much (~50MB).

ddr3 would definitely help, though!

Riverstorm

Even with faster memory wouldn't you still only be as fast as the memory controller (SoC?) allows. You can't push data faster than the CPU/GPU can handle. You can run slower but not faster. It seems like you still would be throttled by the CPU/GPU in some way or the SoC which integrates all the components. I have trouble separating components and what they can do like you do with a PC.

This helped muddy the waters on GPU usage. It sounds like problem B (saturated 3D CPU) could be the real cause of problem A (slow vector units). Everything seems so tightly integrated when using...well a SoC!

I suppose all the integration is about a low cost cheap solution but still pretty amazing. With RAM it definitely seems to be a rob Peter to pay Paul situation. What the GPU leaves the CPU is allocated. I agree most games used very little RAM back in the day but "emulation overhead" whether pertaining to the system (ES), the emulator itself , pre/post processing effects, etc. it really all becomes part of the base requirements to run the game as you can't really separate the resource usage.

I don't know but if you can't utilize 100% of the RAM in some game, etc. the memory split doesn't seem like it would matter? I mean if you did a 512 split down the middle and neither the CPU or GPU is hitting 100% then it seems irrelevant. I know when it comes to virtualization we shoot for as close to 100% as possible barring issues like I/O due spindle count or memory/CPU spikes anything less (which happens all the time) is wasted clock cycles or underutilized.

sudo vcdbg hist
gnuplot task.gpt

will show you how busy the GPU is. (Usually not very...)

It would be difficult to get an overall GPU level of usage. It consists of dozens of HW blocks, 2 vector CPU's, a number of 3D CPU's etc. If one of those becomes saturated, then the GPU is running as fast as it can, but (for example) the vector units may NOT being running at full tilt, so you cannot just add up all the performance from each block. One measure could be overall memory bandwidth, which can sometimes be a limitation, but even that's not much use as you can max out some of the blocks without hitting a memory bandwidth issue. So as you can see, it's not like a CPU graph where you CAN say specifically how much CPU time is being used.

dankcushions

@riverstorm said in Memory Split Does What? Increase or leave alone?:

Even with faster memory wouldn't you still only be as fast as the memory controller (SoC?) allows.

oh sure, but i would hope they would also upgrade the bus before slapping in faster memory, otherwise it would just have to be downclocked :)

I agree most games used very little RAM back in the day but "emulation overhead" whether pertaining to the system (ES), the emulator itself , pre/post processing effects, etc. it really all becomes part of the base requirements to run the game as you can't really separate the resource usage.

you can measure accurately VRAM in real time (so, including the emulation overhead) via vcgencmd, so you can at least measure that, and it's very low. but yeah i wouldn't bother measuring GPU load or anything else - at that point you are better off using GL profilers.

I don't know but if you can't utilize 100% of the RAM in some game, etc. the memory split doesn't seem like it would matter? I mean if you did a 512 split down the middle and neither the CPU or GPU is hitting 100% then it seems irrelevant.

yeah for sure! for emulation on a pi3/2, at the default split (256: GPU, rest: system RAM), you won't max that out.. BUT when doing large compiles you can easily max out the system ram, and then it uses slower, SD card-killing swap. this is why people shouldn't raise the GPU split. helpful for nothing.. unhelpful for something!

Riverstorm

@dankcushions said in Memory Split Does What? Increase or leave alone?:

oh sure, but i would hope they would also upgrade the bus before slapping in faster memory, otherwise it would just have to be downclocked :)

It was more of a compatibility thought when I read that DDR3 would definitely help or maybe it was just a quick wishful thinking of faster memory and a better gaming experience! :)

Is the memory DDR3 (LPDDR3?) compatible with the ARM8 and they used slower memory to keep a price point. Basically is it possible to upgrade the RAM architecture only.

I would assume if the ARM8 supports faster memory (DDR3) and it was a pricing decision then no "bus" modifications would be needed or even downclocking the RAM as the CPU is able to waste clock cycles (idle time) waiting for slower RAM or another way to look at it is the CPU will dictate the clock speed it receives data regardless of RAM clock speed be it faster or slower but not the other way around.

My thought keeps going back to the SoC also. It seems like it's the "traffic cop" (component communication) and would dictate speed/type or at least need to sync the speed between components. Maybe it's just a bridge and works at backplane speeds (thinking like a switch here) leaving clock speeds to the components themselves.

Some CPU's can use both memory types (DDR3 or DDR4) but it's the chipset (i.e.-motherboard) that forces you to use one or the other.

You don't see memory overclocked as frequently it seems. In most cases but not all the returns are minimal vs. saying a quick tweak to the FSB multiplier but some squeeze every percent they can out of their PC and that includes memory.

When you buy a new mobo most times you're also buying a new CPU & memory due to the socket type and memory architecture differences. Your basically forklifting your PC. Possibly reusing the power supply and few peripherals like the CR-ROM & maybe your case, fans, possibly the graphics card, etc. I build all mine from scratch.

BUT when doing large compiles you can easily max out the system ram, and then it uses slower, SD card-killing swap. this is why people shouldn't raise the GPU split. helpful for nothing.. unhelpful for something!

Good point! That seems like a very solid reason for keeping the default allocation split as it will be helpful in certain compiles of some of the emulators or most? I know some apps will leverage every single byte you give it.