Memory Split Does What? Increase or leave alone?

RetroFreak89

@thewinterdojer alright ill guess ill keep it default didnt know what it did rly..

Also i got another question didnt want to make a topic for it but ive used the scraper from the gui menu before but it renamed my roms and messed up everything for example robocop turned into a diff game when i booted it up for example..
I see theres another scraper in the packages called steven???
I wonder does that scraper act the same as the other one?
Or is it safe for me to go ahead and start it?
I rly dont want it messed up again last time had to recopy all my roms over..
Also i dont have a computer so i cant use the universal scraper unless theres a android version? Doubt it

Capeman

I've been playing with memory split off and on for a couple years. On a pi 3, i've found it has no bearing on emulation performance, what it does affect is the speed of rendering for certain themes. Some themes are very graphic intensive, have high resolution backgrounds or other such ram taxing elements.

Upping the vram limit helps heavy themes render better, ive found 400mb of vram to be a nice medium with the modified Simple theme i use. Smooths out the hiccups.

theWinterDojer

@retrofreak89

Also i got another question didnt want to make a topic for it but ive used the scraper from the gui menu before but it renamed my roms and messed up everything for example robocop turned into a diff game when i booted it up for example..

The scraper doesn't actually rename the ROM file itself. It creates a gamelist.xml which changes the name in the menu, but leaves the actual file on your Pi unchanged. I guess you can think of it sort of as a mask for your ROM that can be edited and changed without messing up the ROM underneath. That being said if you delete it from the edit meta data menu it will delete your ROM from the system entirely.

I see theres another scraper in the packages called steven???
I wonder does that scraper act the same as the other one?

Yes, do install Steven Sselph's scraper from the optional packages menu. I believe it's towards the bottom and is just called scraper. His scraper works by hashing the ROM against a database instead of searching by name, so regardless of how it's named if it is a verified ROM it will scrape the correct meta data.

theWinterDojer

@capeman I don't think it's a good idea to up your Vram limit that high, I've seen it's suggested to bring down to 80. The memory split can be effective for graphic intensive themes, but I honestly don't know that much about it. If someone can provide some insight into it I may change mine to work with the Modern TV theme.

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.