reduce memory usage/lower past 32 chunks
On a a system with 4gb shared memory(vram+ram). Wondering how I could optimize memory usage with DH? It won't let me set below 32 chunks
114 Replies
ubuntu is installed to the 32gb flash right?
can you set the sd card as swap? i think you could possibly allocate 3gb to the game, and let infrequently accessed system stuff be offloaded to swap
Not sure. Repartitioning the sd card is a massive pain with the switch so that would be a last resort.
you can swap to file rather than using a swap partition. performance is generally the same whether you swap to a file or a partition
It comes with 3gb zram I believe, and Ubuntu is installed on a 80gb partition
Not sure if zram is swap, but I have noticed a swap file in the root directory
i think a good first step would be switching to a more lightweight desktop environment
1gb at idle is rough
The problem with that is custom builds and kernels need to be created for the switch
Not any arm64 iso, only kde fedora and Ubuntu gnome are supported
do the repos not include other DEs?
I prefer Ubuntu gnome due to better software and touch support. It came 1.6gb idle stock and I have tuned down to 0.9gb
They could work but also fall into the problem of losing touch support and potentially using the joycons to navigate gnome as well
okay that's fair ig. how does the game run with 3gb allocated?
While keeping portability(not needed kb and mouse) I think gnome is only real option
Right now I do 1.5gb to 2gb and I get 50 fps with 4 chunk real and 32 chunks medium LOD
When you allocate ram to MC it only counts CPU ram which steals VRAM since it is shared
That is why it is not higher
disable water transparency, it kills performance on such machines
p much doing twice the render work
Isn't it already disabled on the old chunks?
lid*
LOD autocorrect
LODs have their own transparency system
medium quality with transparency disabled at 720p should let you go up to 6 vanilla chunks, 128 LODs ish
might start swapping like crazy though. you'll have to test
It's loading sd cards are slow
for sure
launching on the rpi5 takes a good 2 minutes
Also like to say overclocking is an options and is built into the switch version of Ubuntu but most of profiles are unstable for me
Won't help with mem but for general performance
Chunks are loading now
increase the memory clock speeds a bit. that typically helps on the switch
default is 1600 according to google (and from what i remember)
try 1800 ish
memory overclocks are usually very stable
I'm not sure if Mem clocks are built in but def possible. GPU and CPU are though
cpu/gpu overclocks would help but not as much
and they can be quite unstable
and with how long ubuntu / minecraft take to start up off sd card it's a 5 minute time loss if the risk doesn't pay off
The LODs are not loading anymore for whatever reason
rejoin the world perhaps
sometimes the queue gets stuck
also if you're on 2.0.1 use the nightly from #links-n-downloads
Wait nvm
huge performance gains compared to 2.0.1
The were all generating behind me for some reason
if you're on 2.0.1 that's TBE because frustum culling wasn't implemented yet
2.0.2 1.20.4 is the version I'm on
Got from 2 days ago
wacky that it's generating behind you then
should start loading in the direction you're looking when first loading in
Similar memory consumption but better performance now that chunks have finally loaded in
It takes very long for 32 LODs which is why I wanted to reduce mainly
initially generating LODs is very slow
once they've been generated they should load fast ish
Trying 64 chunks now just to see
Got any other ideas on memory?
can you post the output of
free -m
? i'm curious to see how you've got swap and such configuredOverall LOD performance with transparency off is very noticeable
since you're at 720p you might want to go all the way down to the low quality preset
this also disables ssao
(rejoin the world after switching anything graphics settings related)
cutting it close but i think there's a chance of this working at 128
the memory usage difference between 32 and 128 isn't massive (couple hundred mb at most)
that's at the low quality preset though. not sure how that will scale at medium
It's worth noting that I have a static 1.5gb dedicated to Minecraft
Rest is Ubuntu + vram
vram usage isn't super heavy with DH
not a worry i don't think
memory usage tends to explode when generating LODs though because it uses vanilla minecraft worldgen under the hood
best bet would be the minimal impact cpu load preset
this does a max of 2 LOD gen threads iirc
That's probably best than since I think it only has 4 total
I lag with anything above low impact aswell
that cpu will already be busy with memory compression and various minecraft main thread stuff
i'm guessing cpu usage will be pretty high even at minimal impact
Once it is all loaded 64 chunk render is only allocating 80-150 mbs memory now
One GC every ~5 secr
Secs
Not bad
what're the GC spikes like?
Not sure how to see CPU usage as I couldn't get mangohud to work here. It is def not GPU bound as f3 menu only shows 60%
Not bad, 56 fps to 51 fps with barely noticeable stutter
slight overclock by maybe 200mhz could help a bit
I believe that could be optimized with jvm args aswell
All I have out of the box is OC high, medium. For GPU and CPU each. I will try OC medium on the CPU but on both it was unstable
gpu overclock in this situation would be kinda wacko anyway
it's only 60% utilized anyway
maybe underclock the gpu a bit for better power delivery?
It was useful when I played on 8 chunk render no LOD
Also just crashed with CPU medium
rip
I don't think I got very lucky with this chip assuming it works like desktop overclocking
I will look into memory overclocking later
yea silicon lottery exists with SoCs as well
the cpu bottleneck will probably disappear when LODs finish generating. once you're back in, try disabling distant generation and wait for LOD tasks to finish, then check the performance
i'm placing my bets on 80+
80+ fps?
considering you're getting just under 60 with distant generation enabled
and that gpu is highly underitilized
(i predict closer to 90 if my rpi5 testing is a somewhat realistic comparison)
Booting into Ubuntu rn
this makes me want to mod my switch (it's a day 1 RCM vulnerable model) but the charger port broke off so i'd have to get another switch to use as a charging station which would be pricey
Also do you know if I still need to take the same precautions with Mem overclocking? I tried it on my desktop once and getting a lot of silent corruption and learning to test the hard way.
memory overclocking is really stable
The port broke? How
just do a 200mhz overclock and you're good
5 ish years of abuse
i always played that thing handheld and since the charger port is at the bottom it was under constant friction
I did even less on my desktop, but it is Corsair ram so not super surprising
Left is a non broken battery connector, right is a broken battery connector. Got the second switch to charge the battery but the connector is so fragile I had to abandon the idea
thing just snapped off the board :trolllaugh:
That's interesting
You might be able to sell the 1.5 switches for a modded one
if you ever plan on replacing your battery, be very very careful with that connector
if anything i'd try soldering on a new port. that could get messy, though
Also if you know soldering the oled and v2 mod chipped switches have much better performance than v1
the OLEDs are great for modding from what i've heard
As far as I know v2 have identical chips but ofc not the OLED screen
Render off
It's send 32 rnd 64 chunk reders just takes forever to load them all
Once they are loaded it runs fine
once everything's generated it'd be best to disable distant generation and set the cpu load back up to balanced
since the only cpu load coming from DH would be that initial load time when joining a world or switching dimensions
I have it on aggressive for testing
400mbs allocation and the blank chunks that haven't been loaded this whole time(bug?) indicate it's still going
I think at this point it's just bugged so I will try new seed
No idea why it fluctuates between 90 and 40 fps despite all chunks loaded
is this while moving around?
i think the GC is exploding trying to load new LODs
Standing still
My guess would be swapping or GC issues
really does sound like swapping
can you access f3 from here or no
Yep
try with a 2gb allocation
and just pray that swapping works well
the lowest i'd ever consider running DH with is 4gb so this is unexplored territory for me
Don't forget the vram either
1gb swap
Will the JVM use swap if it's allocated memory runs out or just OS?
vram usage is so insignificant you probably won't be using more than a few hundred mb at most
everything should use swap when out of memory
But with the jvm its supposed to GC instead right?
you could try like a 3gb allocation for the lols but the system would be swapping constantly. unplayable i think
Swap is now 1.3gb
only once the heap reaches 100% memory usage
but the system will be swapping before this
(possibly)
the hope is that system related stuff is offloaded to swap before the game is
70-40 here
64 chunk
I will try 2.2gb static
Any use in dynamic memory here?
static's your best bet
i'm guessing you mean
-Xms
being the same as your -Xmx
?Yep
Any other JVM arguments you suggest?
https://github.com/brucethemoose/Minecraft-Performance-Flags-Benchmarks is a commonly used one
GitHub
GitHub - brucethemoose/Minecraft-Performance-Flags-Benchmarks: Sane...
Sane, Benchmarked Java Flags and Tweaks for Minecraft - brucethemoose/Minecraft-Performance-Flags-Benchmarks
Also worth noting I think I used 2gb static before this and had worse
But I was also using those ^^ flags so we will try stock here
i haven't had much luck personally with these flags. i always use stock
I'm guessing the flags were not optimized for such low ram
likely that they were optimized for 4gb and higher allocations
On my Linux PC GraalVM 4gb plus their flags worked really well for me
On both server and client performance
have you tried graal on here?
Couldn't get it running with the Linux aarch 64 build
Java command is recognized in the CMD but prism launcher does not want to recognize or accept it
I heard it was built for a more modern chip but may not be true
Oh my switch is at 0% battery rn
linuxing good tonight lads
We will have to stop for today. Not sure why the port can not charge faster than usage on Ubuntu
While it can on switch os
Maybe just firmware Optimization/silent overclocking
ubuntu power management isn't nearly as good
nsss is designed around careful power management
Shouldn't it be irrelevant under load though?
i'm not knowledgeable enough to properly answer
all i can say is that it does matter
@Yeshi (GMT+1) After pregenerating a world on my PC, setting the DH impact to minimal/low, removing c2me, setting chunk update threads to 1, and finding a light stable overclock, these are the results.
DH on the Nintendo switch was a success
🎉
Here I am even GPU limited by the rain particles, and docking at 1080p.
what's undocked run like?
and is this the max render distance it can handle?
i think the next step is to push this as far as possible before it becomes unstable
Was at 48 render
crank it :gamergaming:
48/5 specifically
Docking with the same OC is 50+fps, not gpu bound but I raised DH priority to balanced
Undocking*
nice, nice
128 LODs still loading, can't even see that far with the 6.6 inch 720p screen on the switch, had to dock
Here is a mostly generated 120LOD
It's docked but res is set to 720p still
is fog disabled? if not, try doing so
advanced options -> graphics -> fog