Firestorm is using 14 gb of ram, is it normal?

[Butler Offcourse]

Hello everyone,

Today I was wondering about my ram useage and I realized that Firestorm was using 14 gb of ram. Normally it uses around 6-8 gb. Is it normal? Is it a memory leak? I am using Linux and all those values are from Linux - both the 6 gb useage and 14 gb. I am in a busy beach, this can be the reason? My computer has AMD CPU Ryzen 7,16 gb Nvidia RTX 3080 GPU and 32 gb of ram running on arch linux and hyprland if it matters. And I am using the latest firestorm client 6.6.14.

Also if it matters I am right now in a beach with 55 people. This could be the reason? I don't go to crowded places normaly. And I am using just one second below the Ultra, but I realized that changing it to low did not really make a difference.

EDIT: I teleported out of the place to my skybox and now the ram useage went down to 3.8 GB. So was it the big number of people that caused the high ram useage? I don't care about most of those people there, is there a way for me to decrease the ram useage the next time I have to be in such place? Like derender everyone and render on demand people that I want? is there a setting like that or I have to go and derender manually? Or it was something else that was causing that much ram useage in parallel to the number of people?  Because sometimes when I am working on blender, I may need that ram but I love multitasking too, so I was curious if there is a workaround for those moments.

Thank you!

Edited August 20, 2023 by Butler Offcourse

[Henri Beauchamp]

This amount of RAM usage is in no way ”exceptional”, especially when you push the ”texture memory” slider to the right (increasing both RAM and VRAM usage in the process): each texture in VRAM got two copies in RAM and if your viewer uses , say, 6GB of VRAM for textures, it will use about 9GB of RAM just for the ”raw” and ”decoded” copies. Then, you must add the meshes data, the vertex buffers, the objects data, etc, etc...

2 hours ago, Butler Offcourse said:

I am in a busy beach, this can be the reason?

Yes, this is part of the reason (avatars are very taxing on VRAM and RAM usage, since a modern avatar will wear one or several rigged meshes and many attachments, with materials, high resolution textures, etc).

Draw distance also plays a big role (the number of objects rendered and thus loaded in memory typically increases as the squared value of the DD).

2 hours ago, Butler Offcourse said:

I teleported out of the place to my skybox and now the ram useage went down to 3.8 GB.

Normally, and after waiting for the departure and neighbours sims to disconnect and the associated textures to unload (watch the number in the texture console: CTRL SHIFT 3), your viewer RAM (and VRAM) usage should decrease to return to, almost, the same value as when you started it (almost, because there are some things the viewer will keep in memory until you log out, such as mesh headers). For FS under Linux, I'd say it should return to 3GB or less.

2 hours ago, Butler Offcourse said:

is there a way for me to decrease the ram useage the next time I have to be in such place?

Reduce the amount of ”texture memory” (for the current FS release, it means turning off the ”Dynamic texture memory” setting and using the slider to set the amount manually). Sadly, it also means you will get lower resolution textures. Another thing you can do is reducing the draw distance, provided all avatars are not concentrated in a small area (in which case, it won't help).

[Butler Offcourse]

Hello!

Thank you so much for your answer!

I am in since almost 16 years, and all my computers that I used thruout that time had 16 gb ram, not less and not more. I upgraded my ram to 32 gb just two weeks ago. So that is why I was surprised when I saw 14 gb of ram useage because I was like "what was my computer using when I had only 16 gb of ram?" , well, most probably swap. I've been using linux just for 6 months, before I was using always Windows and MacOS so, the situation must have been the same, with swap disk - even thought I never set it up. If it has it as default, then it must've used it.

Thank you so much for the technical explanation, I didn't know about the connection between Vram useage and Ram useage. That is very interesting to know!

I found out caping frame rate, and I capped it at 60 (compared to 140-160 frames uncapped). Would it help for the ram useage? or may be for the cpu useage? I wanted to do it because SL on my computer uses only 1 core from all the 16 cores available and that one core works 80-90% pushing the heat of the cpu up. Not very much, it remains around 62-70 degrees which is totally normal for my AMD Ryzen 7 5800H, but if i can bring it down, I prefer, so that there is less fan noise.

[Henri Beauchamp]

28 minutes ago, Butler Offcourse said:

I am in since almost 16 years, and all my computers that I used thruout that time had 16 gb ram, not less and not more.

Over years, SL became much more demanding on PC power, which is, in fact, totally normal (likewise, you won't play today's AAA games on PC built 15 years ago)... For today's SLing, 16GB of RAM is barely enough, and 32GB is recommended.

The main ”culprits” are meshes (and ”onion-layered” rigged meshes especially) and materials (3 textures per face instead of just one: and PBR will push that further to 4 textures per face).

28 minutes ago, Butler Offcourse said:

I found out caping frame rate, and I capped it at 60 (compared to 140-160 frames uncapped). Would it help for the ram useage?

No, it won't change a single byte in memory usage, but yes, it does help to keep PCs cool and quiet: it does not make much sense to render at frame rates way over your monitor vertical refresh rate (which is commonly among 60, 120 or 144Hz, depending on your monitor), and doing so causes excessive/useless power consumption and totally superfluous heating (with the corresponding very large noise increase due to fan spinning much faster).

So, using a frame rate limiting is indeed a good idea... Provided your viewer is ”properly coded” in this respect.

If it only allows VSync limiting, then you are out of luck, since it will cause large variations (”hiccups”) in frame rates like 60 to 30fps for a 60Hz monitor and a frame render time varying around 1/60 of a second (if a frame renders in 1/59 of a second, the VSync bit will cause the GPU driver to delay the return from the frame swap OpenGL call by the CPU till next frame and you will get a drop from 60 to 30fps for that frame).

FS is using a varying sleep() call instead (i.e., when a frame renders ”too fast”, it just sleeps the CPU for the remaining time before the total time is 1/60s of a second, or whatever rate you configured it for), which is better, but not ideal either: it avoids the fps ”hiccups”, but slows down the UDP messages, textures and mesh decoding tasks (which are updated by the viewer main thread, which also happens to be the render thread).

For the Cool VL Viewer, I instead implemented a ”smart” limiter: when there is ”some time left” before starting to render the next frame, it uses that time to decode more stuff, and only after all the queued tasks are finished, does it sleep the CPU. With this algorithm, the viewer rezzes even faster than without frame limiting (because the time spent to uselessly render frames that your monitor would never display is instead spent decoding and updating stuff).

Edited August 20, 2023 by Henri Beauchamp

[Aishagain]

On the topic of viewer Texture RAM use, I have observed that the latest version of Firestorm for Windows, 6.6.14 seems to have a greater appetite for RAM than its predecessors, most recently 6.6.8.  At a specific location, a fairly busy club, 6.6.8 would top out at about 6.5GB, but 6.6.14 stabilzed at 10.5 GB.

[gwynchisholm]

Something may be off there, that does look more like a memory leak.

In a club with 75 people in it, at 4k max settings 1024m render distance and shadows set to 4.0 scaling, and giving everything time to load, i got this:

Managed to use 13gb of video memory, but only ~7gb of system ram.

Though with it changing when you went to a different space, it may have been literally just the space having massive amounts of textures or something in it causing that. Ive never seen firestorm hit double digit ram usage before, i guess it wouldnt be impossible for some places to be so full of 4k textures or something that it would do that.

 

[Henri Beauchamp]

15 hours ago, gwynchisholm said:

Something may be off there, that does look more like a memory leak.

In a club with 75 people in it, at 4k max settings 1024m render distance and shadows set to 4.0 scaling, and giving everything time to load, i got this:

Managed to use 13gb of video memory, but only ~7gb of system ram.

Well, yes, there is a VRAM ”leak” in (almost) all viewers, due to how LOD-boosted textures are made ”no delete” by the viewer, meaning you will accumulate them over time and they will occupy uselessly some RAM and a lot of VRAM. To see it in action: log in (preferably in a sky box to consume as little VRAM as possible), check the VRAM and GL bound textures usage in the texture console (CTRL SHIFT 3), then TP to a busy club or venue; wait for everything to rez and return to your login location, wait 3 minutes for the sims to disconnect and the textures to get cleaned up from memory, then check again the texture console: the numbers will be (sometimes much) higher...

The ”almost” above is because I worked around this in the Cool VL Viewer by:

• Using more sparingly the ”no delete” attribute (i.e. only where it is actually needed, such as for UI textures or sculpty textures).
• Implementing a force-cleanup algorithm for boosted textures that have not been used in a while.

[Feuerblau]

And that issue is what drives my viewer in some occasions into 16GB of VRAM till the point it allocates stuff to the shared memory using system memory.
That leads to a performance loss from above 200 at home to 30FPS at home.
It's annoying, doesn't happen all the time, just "random" at certain points.
It also happens in any point of time. Visiting a crowded place also sometimes doesn't change the VRAM usage at all. It swings around 8GB VRAM. 
But when the performance loss happens, it's always above 14 up to 16GB using all VRAM it gets.
And it starts with texture trashing as well before crashing the performance. (Also maybe an issue of Firestorm and the dynamic Memory usage that FS gets the available memory wrong or just screws it up stuffing more and more into VRAM.)

I also had once the issue that at an event the whole PC got laggy when i zoomed in on a vendor screen, or more so the wall the vendors were mounted to, on said event. When zooming out, all back to normal.
Means: My second screen while watching youtube, the videos went stuttery and laggy when zoomed in on said vendor and went back to normal when zooming out. Never had that happen before.

And i got a 5950X in my system, while it was idling around at ~8% with FS active plus the youtube tabs.
While my systememory doesn't matter much (64GB) i mostly ignore a high RAM usage but it doesn't change much if i remember right.
But my GPU spiking to 16GB is insane and makes said VRAM leak very visible.

It's either an AMD issue or a Firestorm issue. With my lack of knowledge i can't pinpoint the cultrip though.
I just can remember that at a certain poin in the past, that stuff wasn't the case. And as far as i know, my old PC with a 1080ti never ran into that issue at all in the past.
My thought is that AMDs "new" OpenGL fix in their drivers is a mess or at least something is off with it.

At least, if it runs fine, AMD users got mostly the performance nVidia users get.
But with that issue... nah.

Edited September 11, 2023 by Feuerblau

[Nyayr]

I fixed it in a way (had this issue a year now first with pink flashes and crashes later just a freeze) I rolled back to 22.5.1 but read rolling back to 22.11.XX works as well. The newer 23.XX amd drivers are the problem with more openGL games, where it keeps draining VRAM> then starts using Ram and it freezes or crashes eventually, if you like me only got 16gb and FS goes to 12-13gb.

Edited September 26, 2023 by Nyayr
more info