Jump to content

Newest Firestorm version - lag monster


Recommended Posts

I had last week upgraded to the newest version of FS (Phoenix-Firestorm-Releasex64-6-4-21-64531). The release notes said it was trying to do image decompression multi thread... but whatever. It felt slower than the previous, I had 2 high lag events (weddings) deffo seems more sluggish than usual, but my non scientific lago meter test is my home. I live in main land in the sky, and without "atmosphere Shaders' or 'advaced lighting model' I almost always hover about 270-300FPS up there. The newest version I had noticed was staying about 170-220 fps. While there isn't any work for the system to do up there, it always seems to be a good indicator of how it will perform on the ground with 'everything on'

In any case I rolled back to the previous version for now. Maybe some bugs yet to work out with the new 'multi thread' scheme. Not sure anybody else has tried the new version and found similar results or not - maybe it's just me. I'll post my specs for reference

 


CPU: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz (3792 MHz)
Memory: 32671 MB
OS Version: Microsoft Windows 10 64-bit (Build 19042.1110)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce GTX 1080/PCIe/SSE2
Graphics Card Memory: 8192 MB

Windows Graphics Driver Version: 30.0.14.7141
OpenGL Version: 4.6.0 NVIDIA 471.41

Texture memory: Dynamic (2080 MB min / 24% Cache / 10% VRAM)
VFS (cache) creation time (UTC): 2021-8-4T10:57:14 

  • Like 2
Link to comment
Share on other sites

2 hours ago, Jackson Redstar said:

The release notes said it was trying to do image decompression multi thread... but whatever. It felt slower than the previous

If your computer's processor and/or GPU has hiccups with enabled multithreaded image decoding you don't need to revert to the previous version. The changelog for 6.4.21 clearly states, that "(...) any users that have problems should flip the setting to 1 for the old single threaded behaviour. (Preferences → Graphics → Hardware Settings → Image Decode Concurrency)" - this way you won't miss any security patches or features while allowing the viewer to utilize hardware as before.

1 hour ago, Liv Simondsen said:

on my first login textures takes a lot more to load

From the Firestorm's release notes...

Quote

Please note: This update will clear your cache on first launch and so you may find things rendering slowly at first. This is unavoidable, to be expected and not a bug. Please give it time.

 

Edited by panterapolnocy
  • Like 1
  • Thanks 6
Link to comment
Share on other sites

I can't comment on windows but I have been using the latest Firestorm on Linux an what I have noticed is that it seems slow to empty out the textures it no longer needs.

I might be misinterpreting what I saw, but this what what made me come to that conclusion.

1) Visited a welcome centre with quite a lot of stuff around, particularly mesh.

2) Checked HTop and saw how much RAM had been grabbed.

3) TPed to a sandbox, effectively nothing but land.

4) checked Htop and saw no change in RAM usage.

5) Shot up to 4000 metres to clearre video ram (old trick that might not work any longer)

6) Checked Htop, no change in RAM usage.

7) Logged out, relogged into the sandbox

8) Checked RAM usage, minimal as I would have expected.

 

Link to comment
Share on other sites

I've updated. I find scene render much faster. I also find it often gets slow rendering avatars and profile pictures.

I do find that my FPS had dropped, significantly. I'll do a comparison with the previous version some time today.

PS: I did test the viewer and compared it to the previous v6.4.13. The two are very similar FPS-wise. You can see the comparison and my thinking here.

Edited by Nalates Urriah
Link to comment
Share on other sites

Firestorm now has "opaque water" as an option for advanced lighting in the graphics preferences. Unless transparent and reflective water is desired for boating or photography, using opaque water provides a significant boost to the framerate while still enjoying materials, shadows, and ambient occlusion. This wasn't possible on the previous version of Firestorm. Even if you can't see water, it's impacting your framerate if you're anywhere near the ground level.  

Edited by KjartanEno
clarification
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, KjartanEno said:

Firestorm now has "opaque water" as an option for advanced lighting in the graphics preferences. Unless transparent and reflective water is desired for boating or photography, using opaque water provides a significant boost to the framerate while still enjoying materials, shadows, and ambient occlusion. This wasn't possible on the previous version of Firestorm. Even if you can't see water, it's impacting your framerate if you're anywhere near the ground level.  

This was an awesome add to the viewer.  I'm able to run in busy places with material and everything where before, I couldn't just turn transparent water off and use those settings.  Definitely a fps booster.

Link to comment
Share on other sites

On 8/4/2021 at 4:15 AM, Jackson Redstar said:

I almost always hover about 270-300FPS up there.

/me sheepishly try’s NOT to locker-room stare at the ridiculously well hung FPS that dangles between his legs while whispering to myself, “size doesn’t matter, it’s what you do with it that counts.”

  • Haha 5
Link to comment
Share on other sites

Just my two pennorth:  for me this version of FS is approximately 10-25% better FPS at  any given setting,though the gains seem more noticeable at high/ultra graphics settings.  As to loading, it seemed no differnt to me on first startup and I would expect slow loading of textures at first as Pantera notes above. AV whitelisting was as per all previous versions.

The addition of an asset cache may make a difference once I am running mature caches, I must wait and see. 

One change that puzzles me (mere curiosity on my part) is that during the viewer start up after "detecting hardware" I see "Loading Firestorm" rather than the "initializing VFS"...I wonder what that indicates?   The final "initialising cache" message is unchanged.

Link to comment
Share on other sites

35 minutes ago, Aishagain said:

One change that puzzles me (mere curiosity on my part) is that during the viewer start up after "detecting hardware" I see "Loading Firestorm" rather than the "initializing VFS"...I wonder what that indicates?   The final "initialising cache" message is unchanged.

With the new cache system VFS has been retired so that message just replaces that during that initial startup phase.

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

The new cache system doesn't seem to be much of an improvement, if at all. If I go back and forth between two sims, stuff is still grey for a significant amount of time even though it was rezzed during my previous visit and thus should be in cache. My caches are set to max sizes.

Edited by Candide LeMay
Link to comment
Share on other sites

5 hours ago, Candide LeMay said:

The new cache system doesn't seem to be much of an improvement, if at all. If I go back and forth between two sims, stuff is still grey for a significant amount of time even though it was rezzed during my previous visit and thus should be in cache. My caches are set to max sizes.

The new cache only affects assets - grey are the textures and they are not affected by this change.

  • Thanks 1
Link to comment
Share on other sites

When i click the FS icon I get 'detecting hardware' then the loading textures etc almost instantly, then it changes to 'Loading Firestorm'  and sticks on that for up to 5 minutes before giving me the log on screen.

Didnt have this problem with the old version tried reloading but still the same, anyone any idea why it takes so long?

Link to comment
Share on other sites

On 8/4/2021 at 6:14 AM, panterapolnocy said:

If your computer's processor and/or GPU has hiccups with enabled multithreaded image decoding you don't need to revert to the previous version. The changelog for 6.4.21 clearly states, that "(...) any users that have problems should flip the setting to 1 for the old single threaded behaviour. (Preferences → Graphics → Hardware Settings → Image Decode Concurrency)" - this way you won't miss any security patches or features while allowing the viewer to utilize hardware as before.

I just updated last week from the last Windlight FS to the current so cannot compare to the previous FS.  Even though I have a new very spiffy computer FPS took a very big hit (I expected that from comments).  But textures were not loading well AND I could see my body and clothes (which I assume would be cached since they are always with me) load VERY slowly.  I typically have "see friends only" turned on so other avatars weren't in the mix.  

 

Changing the Image Decode Concurrency seems to help quite a bit. I went to two new to me places that I visited a couple of days ago and textures loaded much faster, no body parts floating in air and FPS more than doubled. That is a very unscientific test of course.  But suggesting that change may help other folks having issues.    I run on mid ultra with draw distance about  120 and shadows (high quality) turned on. 

CPU: AMD Ryzen 7 5800 8-Core Processor               (3393.62 MHz)
Memory: 16310 MB
Concurrency: 16
OS Version: Microsoft Windows 10 64-bit (Build 19042.1165)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce RTX 3070/PCIe/SSE2
Graphics Card Memory: 8192 MB

Link to comment
Share on other sites

Updating:  Not sure what to say on this as I went somewhere totally new ten minutes after posting this and it took forever for textures to load. So can't say if the change was really better or NOT.  "I" loaded better with no floating body parts. Framerate is 12.  LOL.   So guess I will change back.  Still worth a try though. 

 

OK. This is getting to be a pain. Each time I quote something it gets put on hold and put into pink. HERE was my comment to the info about changing a setting in Graphics Preferences. Hopefully it will go through (some have never ever posted).

Sorry for the mess here from the copy and paste. 

I just updated last week from the last Windlight FS to the current so cannot compare to the previous FS.  Even though I have a new very spiffy computer FPS took a very big hit (I expected that from comments).  But textures were not loading well AND I could see my body and clothes (which I assume would be cached since they are always with me) load VERY slowly.  I typically have "see friends only" turned on so other avatars weren't in the mix.  

 

Changing the Image Decode Concurrency seems to help quite a bit. I went to two new to me places that I visited a couple of days ago and textures loaded much faster, no body parts floating in air and FPS more than doubled. That is a very unscientific test of course.  But suggesting that change may help other folks having issues.    I run on mid ultra with draw distance about  120 and shadows (high quality) turned on. 

CPU: AMD Ryzen 7 5800 8-Core Processor               (3393.62 MHz)
Memory: 16310 MB
Concurrency: 16
OS Version: Microsoft Windows 10 64-bit (Build 19042.1165)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce RTX 3070/PCIe/SSE2
Graphics Card Memory: 8192 MB

Edited by Chic Aeon
adding info
Link to comment
Share on other sites

It is late, and I am very tired, apologies for any silly typos and any stupid mistakes but I think that this summarises the key points.

The changes that are in the latest FS that affect performance are almost entirely off of the main thread, as such there will be almost no FPS improvement, there is a small reduction in the idle processing and a possibility of beneficial side-effects through the other changes but given the measurement uncertainty (the variance or jitter) in the viewer FPS I don't think for a second that anyone would be able to detect that reliably. Any repeatable changes in FPS would be very very surprising to me, the placebo effect cannot be discounted in all these observations.

TL;DR This viewer release IS overall faster than the previous courtesy of a handful of tweaks, and observed based on a number of controlled benchmarks conducted on hardware that I own. The changes I detail below should imply a general speedup of scene building and rendering but not in FPS, as always your mileage may vary. *shrugs* 

If you are seeing a large slow down in FPS  (or indeed a large increase) it is very unlikely to be anything that we have done as there are no changes that are expected to have that effect (good or bad).

The key (potentially) performance related changes are:

New disk cache : Should mean faster cache retrieval but frankly it is unlikely to make much difference. It will almost certainly have no impact at all on "new to me" places as these are all going to be stuck on network retrieval before they even reach the cache. Network fetch is conducted in subsidiary threads.

Concurrent image decoding: This is the decompressing of jpeg2000 data into RGBA data that is ready for the GPU. There is an interaction with the disk cache here as we load the file, it is then passed to the KDU jpeg library for decoding. There are numerous threads doing this now, so what we can say with certainty is that given say 2000 textures to load and 4 threads to do this on, the total time to process these has reduced significantly. This means that the decoded texture data is ready for use earlier than it was previously, we are also using more of the CPU resources of the machine that previously and as this is done on separate threads it is not impacting the FPS (for good or ill)

Faster mesh decoding: mesh data (each LOD) is sent as a blob of zip compressed bytes. Previously these were decoded using a temporary buffer and copied into place. We have removed the intermediate buffering and this leads to an overall reduction in time taken, but also reduces memory and cache churn which has an effect on latency. If this change has an effect it is in making the mesh available sooner than before, this means that shapes will resolve from "grey blobs" to "grey meshes" quicker than they did before.

Putting these together what would I expect the typical user to notice? Not very much. None of these are on the main thread and thus the FPS is going to remain fundamentally the same as the previous release. 

As always, there are a heap of other changes in any release and while none of those are expected to impact the FPS for better or worse, never say never. 

While the FPS should remain largely the same, the textures may appear faster esp when previously cached (and thus not reliant on the vagaries of network fetching) and meshes will take their form a little faster than before. For me this gives things a slightly more robust feel. It is hard to say that things are "faster" but they feel as though things are "ready" sooner, which is pretty much what I would hope for. Given that a new scene after a TP arrival takes many 10s of seconds to resolve any marginal improvements here are hard to quantify without explicit tests that do not rely on the fallibility of human observation, or the dynamics of the SL interactions.

If things are markedly slower then I would suggest a careful review of all of your AV exclusion rules, time and again this is the culprit even when people swear black is white that it is not. You don't have to convince me, be honest with yourself, and do yourself a favour and double, triple, quadruple check those until you develop OCD about it.

Make sure your cache is on the fastest storage you have.

When you are "benchmarking" make sure that you do everything that you can to create the same scenario. In particular, make sure that you have the same number and type of avatar in the scene if you have any expectation of even approximate comparison. Use pre-cached textures, this means you will need to pre-cache before each run because of the different cache format. If you do not use pre-cached textures then you are adding a large uncertainty into the mix. Even with a cleaned cache a subsequent fetch of a texture will likely hit an edge server for the CDN, the assets having been cached as near to you as the CDN can achieve. An initial fetch on a UUID that has never been seen before, (by you, or anyone else using SL in the same geogrpahical partiiotn that the CDN allocates you to) has a higher overhead as it will need to be fetched from the central servers. 

Review all the settings, shadows, ALM, DD, LODmultiplier etc etc

Finally, if you have a really old CPU, or simply don't believe the threaded image decoding is adding value set the concurrency level to 1 and this will behave almost identically to the previous release, wherein a single thread (not the main) is responsible for all the decoding. In all other cases I strongly advise leaving it at 0 (the default)

 

 

 

 

 

  • Like 3
Link to comment
Share on other sites

11 hours ago, JonforM Coeur said:

When i click the FS icon I get 'detecting hardware' then the loading textures etc almost instantly, then it changes to 'Loading Firestorm'  and sticks on that for up to 5 minutes before giving me the log on screen.

Didnt have this problem with the old version tried reloading but still the same, anyone any idea why it takes so long?

This in particular sounds very much as if you do not have your cache folders whitelisted in you AV.

Try this https://wiki.firestormviewer.org/antivirus_whitelisting

 

  • Like 1
Link to comment
Share on other sites

I'm not sure what to think of this latest release.. it's left me a bit confused to be honest O.o

Firstly, my cache didn't clear on start up like it should have. Not sure why that occurred. I do have my cache stored on a separate hard drive so I wonder if that could be it ?  I also didn't do a clean install since FS say it isn't needed anymore. Maybe that's also a factor.

Anyway, my observations so far is that I am generally seeing an slight FPS improvement at any place I visit, anywhere from 3-10 fps on my normal settings. However, rather oddly, when i bump up my settings to one of my higher presets ie: advanced lighting on, full shadows etc, I am seeing a much larger increase in performance. I need to do some more testing but at the moment, it seems like I get more FPS with high quality graphics settings over normal settings - that's both odd and surprising.

The one thing that hasn't changed though is seeing these constant grey textures when I return to a place. I've seen others mention this previously and it's really annoying. When returning to a place already visited, the textures should rez faster due to being cached, but with these last few FS releases, this seems totally backwards, as though the viewer cant locate the textures in the cache.

Link to comment
Share on other sites

On 8/12/2021 at 8:00 AM, Eowyn Southmoor said:

Anyway, my observations so far is that I am generally seeing an slight FPS improvement at any place I visit, anywhere from 3-10 fps on my normal settings. However, rather oddly, when i bump up my settings to one of my higher presets ie: advanced lighting on, full shadows etc, I am seeing a much larger increase in performance. I need to do some more testing but at the moment, it seems like I get more FPS with high quality graphics settings over normal settings - that's both odd and surprising.

It can be the case, it comes with one of those annoying "it depends" tags. When you have settings set low some things are moved from shaders on the GPU to being processed on the CPU. If, as is the case for the majority of people with a semi-modern graphics card, you are CPU bound in SL then this is definitely going to make you slower overall as it is increasing the load on the CPU that is already working hard while leaving the largely idle GPU twiddling its thumbs. 

It really depends on a great number of things.

On 8/12/2021 at 8:00 AM, Eowyn Southmoor said:

The one thing that hasn't changed though is seeing these constant grey textures when I return to a place. I've seen others mention this previously and it's really annoying. When returning to a place already visited, the textures should rez faster due to being cached, but with these last few FS releases, this seems totally backwards, as though the viewer cant locate the textures in the cache.

Constant grey textures, meaning that they never rez?

At a high level, there are 3 factors that affect texture rendering

1) How quickly they can be retrieved (Network or Cache - check whitelisting, make sure your cache is on a fast drive if possible.)

2) How quickly they can be decoded and made ready to use (Concurrent decode helps here - the size of textures affects this a lot.)

3) How quickly they can be moved between CPU and GPU. (The size and number of textures in a scene affect this a lot - this is harder to quantify as it comes down to a mix of RAM and VRAM and bus - once the texture is decoded it is sitting in RAM but needs to be sent to the GPU to be used, the sheer number of textures fighting to be shown is a typical bottleneck here but it is very dependent on you hardware)

Ironically, with the potential for mesh to "form" faster, you are more likely to see a fully rezzed object with no textures than you were previously. In the past it took a bit longer to unpack the mesh so you didn't see the model as quickly. This can add to the feeling of things being slower (whether they are or not). 

It is impossible really to comment on general impressions of speed or slowness without actual benchmarks there are far too many variables in SL.

One other thing  to keep in mind is that things getting slower over time does not necessarily mean that the viewer has become slower. Quite often the scenes have become more complex, so it is always best to do side-by-side comparisons rather than rely on historical data unless you are 100% sure that the scene is the same. Things like this are why it is so notoriously hard to benchmark anything in SL.

  • Like 2
Link to comment
Share on other sites

@Beq JanusSince you seem to be the fount of a great deal of techy knowledge on FS can you explain this phenomenon I am seeing with the current Firestorm?

I have always had to lower my settings at crowded events such as clubs and I used to set max non-impostor avs low-ish (12-15).  Now I find that the more non-impostor avs in a scene the slower and more jerky my viewer gets (Yes I whitelist everything): if I increase non-impostors until most, if not all the avs are moving normally (say c20), my FPS only drops fractionally, if at all and the jerkiness disappears.  That is counter-intuitive to me, so what is happening?

My CPU is a Ryzen 9 3900 and my GPU an Nvidia GTX1660Ti, I have everything on SSDs and 32GB RAM.

oh and please tell me how to type better, you would NOT believe the number of corrections I needed on this text!

Edited by Aishagain
typos
Link to comment
Share on other sites

1 hour ago, Aishagain said:

I have always had to lower my settings at crowded events such as clubs and I used to set max non-impostor avs low-ish (12-15).  Now I find that the more non-impostor avs in a scene the slower and more jerky my viewer gets (Yes I whitelist everything): if I increase non-impostors until most, if not all the avs are moving normally (say c20), my FPS only drops fractionally, if at all and the jerkiness disappears.  That is counter-intuitive to me, so what is happening?

I guess it depends to some extent on what "jerkiness" means. imposters only update periodically and are thus jerky by definition but I am pretty certain that is not what you mean. The imposter rendering is not great in SL. You still have to render the entire avatar, attachments and all, but you don't do it quite so often. I've not actually measured imposter render cost directly but I would assume it to be, per avatar, higher for one frame (a cost which is supposedly amortised over multiple frames to make it worth while).

This is pure speculation, as I have not tested any of this, but if you have a large number of avatars being rendered ready for impostering, and given that this takes a bit more effort and they then need to be redrawn some defined period later (IIRC redraw is triggered by a number of things, time, camera movemment etc) then every time we recalculate the imposters we get a burst of activity and a longer than normal frame time, followed by shorter frames. this is by definition a jerky experience. On the other hand by rendering all these mesh avatar monstrosities you are getting a consistent, but lower FPS. The logic to my reasoning only really holds up where for your specific hardware and the circustances in the scene being drawn imply that the cost saving of the imposters is low relative to the true cost (that's a lot of ifs and buts and guesses)

There have been a number of changes to how jelly dolls are rendered that have flowed down from the lab in recent releases. These are related to imposters and it is possible that those changes have tipped the balance against the imposters.

As I say, lots of speculative thoughts in that. I will try to measure the reality at some point and see if I can see any weirdness.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Beq Janus said:

I guess it depends to some extent on what "jerkiness" means. imposters only update periodically and are thus jerky by definition but I am pretty certain that is not what you mean. The imposter rendering is not great in SL. You still have to render the entire avatar, attachments and all, but you don't do it quite so often. I've not actually measured imposter render cost directly but I would assume it to be, per avatar, higher for one frame (a cost which is supposedly amortised over multiple frames to make it worth while).

This is pure speculation, as I have not tested any of this, but if you have a large number of avatars being rendered ready for impostering, and given that this takes a bit more effort and they then need to be redrawn some defined period later (IIRC redraw is triggered by a number of things, time, camera movemment etc) then every time we recalculate the imposters we get a burst of activity and a longer than normal frame time, followed by shorter frames. this is by definition a jerky experience. On the other hand by rendering all these mesh avatar monstrosities you are getting a consistent, but lower FPS. The logic to my reasoning only really holds up where for your specific hardware and the circustances in the scene being drawn imply that the cost saving of the imposters is low relative to the true cost (that's a lot of ifs and buts and guesses)

There have been a number of changes to how jelly dolls are rendered that have flowed down from the lab in recent releases. These are related to imposters and it is possible that those changes have tipped the balance against the imposters.

As I say, lots of speculative thoughts in that. I will try to measure the reality at some point and see if I can see any weirdness.

speaking of imposters, what would be great if we could have a priority list of always render (a specific avatar) , not just (I presume) impostering based on distance to camera. For instance, when I video a wedding, I always want the couple and the wedding party to be in full render, everyone else can be imposters (for the most part) But then again I only usualy see a few FPS difference between choosing to imposter alot of avis vs just letting everyone fully rezz, unless its a giant gathering of 70+ avies at the event

Link to comment
Share on other sites

46 minutes ago, Jackson Redstar said:

speaking of imposters, what would be great if we could have a priority list of always render (a specific avatar) , not just (I presume) impostering based on distance to camera. For instance, when I video a wedding, I always want the couple and the wedding party to be in full render, everyone else can be imposters (for the most part) But then again I only usualy see a few FPS difference between choosing to imposter alot of avis vs just letting everyone fully rezz, unless its a giant gathering of 70+ avies at the event

"right click - render -> fully" *should* do that

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...