Henri Beauchamp

Well, I (quickly) tried Mesa3d+Zink (v23.0.3) today, and with my NVIDIA card, it almost immediately crashes the viewer after login... Might be due to core profile and multi-threaded shared GL workers though...

This is not Firestorm's fault: Windoze does not offer any mean to find out the actual frequency for the CPU core running a software, and believe me, I tried hard to get it for my own viewer... ”Modern” processors with turbo mode simply get reported the TSC frequency, sadly. Amusingly, I managed to find a method to get the turbo frequency while the Windows build of my viewer runs via Wine under Linux (i.e. Wine folks got the corresponding system call right, unlike Micro$oft) ! 🤣

Indeed... Get the Cool VL Viewer, enable the multi-threaded GL image worker (”Preferences” floater, ”Graphics” tab, ”GPU/GL features” sub tab, set ”OpenGL worker threads” spinner to -1) and restart. Then set ”Advanced” -> ”Rendering” -> ”Textures” -> ”Boost proportional to active fetches”, and enable the smart frame rate limiter: in the ”Preferences” floater, ”Cool features” tab, ”Misc.” sub tab, set ”Frame rate limit” spinner to 60 (or your monitor VSync rate) and enjoy ! Want even faster rezzing when moving around ?... Reduce the ”TextureFetchBoostRatioPerFetch” (defaulting to 200) at, say 50 or even 20 (not recommended for non-gamer PCs, however: suitable for 12+ cores CPUs only, if you do not want stutter caused by excessive cores load). Oh, and do enable the SMAA anti-aliasing shader to replace the lame/blurry FXAA one (”Preferences” floater, ”Graphics” tab, ”Renderer settings” sub tab); courtesy of Rye Mutt (I backported his SMAA implementation from Alchemy). I find your approach (rewriting a viewer from scratch) quite admirable and even heroic, but IMHO the amount of work and time you invest in this would likely be more profitable if invested in the current viewer code base (that can still be improved in very large proportions, especially if the renderer is migrated to Vulkan). For example, and without even touching the renderer itself, it would be great if you could contribute your method to evaluate the required texture LoD in real time; my optimizations are ”just” about pushing more fetching/decoding/caching work to (more) threads and increasing the number of required LoD calculations per frame in smart ways (such as during the frame limiting delays, or when a lot of textures are being fetched), but the real solution would be to have the required LoD evaluated in a thread.

Yes, the newer ”Resizable BAR” setting is just a ”better version” for newer PCIe bus and graphics cards versions... No, it won't have it, unless your motherboard maker provides an updated UEFI version with it added... Worth checking on their web site. Yes, this is the drawback... Lowering your draw distance would reduce the texture memory usage and thus the blurry textures. Alternatively, give a shot at the Cool VL Viewer (I spent quite some time optimizing the code for the texture fetcher and discard bias algorithm, and you should not have to worry any more about freezes and stuttering).

Yes, this is exactly the same issue, and ”camming around” can also cause the same symptoms as those I described, since this is also a sudden change in the FOV, that may cause a temporary overshoot in 4GB mapped memory window limit. It might however also be due to an overshoot in the total VRAM usage (at which point, the driver has no other choice than spilling textures over to the CPU RAM, causing, here again, stutter and ”short” freezes). First and foremost, do check in your BIOS/UEFI for those ”Above 4G decoding” or ”Resizable BAR” settings: the first should be present in pretty much every BIOS/UEFI, even for old computers, while the first will only appear (and sometimes only once the first setting got checked) in newer UEFI versions (approximately one year old or less), and only when the CSM (BIOS compatibility mode) is disabled in the UEFI. Check your motherboard documentation for how to enter the BIOS/UEFI (usually typing F2 or DEL *just* after the keyboard is initialized on reboot; this might be tricky and require quick repeated key-presses on one of those keys), and where to find the said setting(s) (normally somewhere in PCI advanced settings). If you have them checked and still experience the stuttering/freezes, you will need to disable Firestorm's ”Dynamic Texture Memory” setting (in ”Preferences” floater, ”Graphics” tab, ”Hardware Settings” sub-tab) and then use the ”Viewer Texture Memory Buffer” slider instead (keep it at the max 2048MB)...

On systems which BIOS/UEFI lacks an ”Above 4G decoding” setting or the newer ”Resizable BAR” setting in their PCIe configuration, or with these disabled, you will also experience bad stuttering (pretty much second-long freezes) when the texture VRAM usage overshoots the 4GB limit... This can be easily reproduced by pushing the textures memory setting beyond 4GB in viewers allowing it (or turning on their VRAM usage auto-limiting setting, when they got one, such as in the latest FS release), and then standing in a textures-heavy sim with 256m draw distance, waiting for all textures in FOV to load, then rotating your avatar in place to face the opposite direction. This is one of the reasons that made me add a bound GL texture limit setting in the Cool VL Viewer; it limits the said textures to 2.5GB by default, whatever the configured ”Texture memory” (being a soft limit, which the discard bias algorithm is using in excess of textures memory usage and CPU RAM usage, it must kick in before the phenomena would appear, and given other GL textures usage in the viewer, it usually appears around 3GB of GL bound textures). With the recent changes brought to the viewers VRAM management and the newer graphics cards with 8+ GB of VRAM, this issue became rather prominent...

Here is what changed; it's not me, but LL who changed their stance... 😜

Sorry, I do not use Discord at all. Privacy (*) issues and (to add to the already bad picture), web compatibility issues with my browser (Pale Moon). (*) E.g. (these are just a couple articles, and you will find many more in the same vein with a web search): https://www.techradar.com/opinion/discords-ai-features-violate-our-privacy-and-its-time-we-pushed-back and: https://cybernews.com/privacy/discord-privacy-tips-that-you-should-use/

Then the issue is likely with your system, not the viewer. Though, you could try other TPVs to make sure; the Cool VL Viewer is a good candidate, since its code base diverged a lot from LL's viewers over the past 15 years (unlike v2+ TPVs), and will likely not have the same bugs as LL's viewer and its derivatives. This is not a log, but just the ”About” info, which is interesting nonetheless, to pin-point potential hardware or drivers limitations, but won't show what went wrong in your case. A log is created at each and every viewer session. This Wiki page tells you where to find it for LL's official viewer (and for the Cool VL Viewer as well); most other TPVs, use a different sub-directory than ”SecondLife/” however (for Firestorm, look at a ”Firestorm<something>/ sub-directory, as the same level as the ”SecondLife/” one). Then, in this directory, look at the logs/ sub-directory where you will find the *.log files (post the most recent, corresponding to the viewer session you just closed and which went wrong). Good question: since it is (likely) not a viewer-specific issue, posting in the viewer support channel (e.g. as JIRA bug for SL official viewer) would be inappropriate/inefficient. You may try posting your log here (zip it first !), in the hope someone will be able to identify the issue, or you could create a support ticket, explaining your issue (using/referring to LL's official viewer, since LL won't provide support for TPVs), and attaching the zipped SecondLife.log to that ticket...

You know, without the viewer log, it is pretty much impossible to diagnose your issue; at best, people can do wild guesses and give generic advices (like with phone hot-lines silly/stupid question: ”did you plug your computer into the mains ?”)... So, my one and only advice is: provide a viewer log, and since it is Firestorm-related, do it via their own support channel(s)...

LL reverted some changes they did in the performance viewer, but they did not pick up my (working) fix... You could create a JIRA issue, giving reproduction steps (affected items, graphics settings, viewer version), and screen shots comparing what you get and what you should be seeing (use an older SL viewer or the Cool VL Viewer for the latter).

I think it would be a good idea for LL to collect such info and then publish the list of routers that definitely do not make it, to prevent other SLers to get into troubles should they buy them... There could be a page in the SL FAQ for such a list.

Not a surprise to me: I spent a considerable amount of time fine-tuning the textures algorithm, and then experimenting and stress-testing it, and did so on 4 different PCs, and in many different situations (over crowded clubs, scenic super mesh-heavy and texture-heavy sims, hour-long travels across sims in the main land with 512m DD, etc). For the benefit of any TPV developer reading this, here are my findings: At least with NVIDIA cards, and even for the ones with 8GB of VRAM, you should never overshoot 3GB of bound texture memory, or will get second-long freezes; this lead me to modify the discard bias algorithm to properly react in time, before such an occurrence would happen (often seen when turning your avatar around in textures-heavy sims and with large draw distances), and to cap the bound texture usage ”soft limit” to 2.5GB by default, even when the viewer is configured to use more than 6GB of texture memory. Enough *texture* VRAM must be left free (10% of the total texture VRAM as detected on viewer startup, or 1GB, whichever is the smaller): should the VRAM get too full, the driver will spill textures over the RAM, causing seconds-long freezes. This poses a problem with iGPUs (no VRAM, so no GL call to get the free VRAM) and with AMD GPUs under Windows (their OpenGL call for reporting the free texture VRAM is bogus, and most often reports silly huge numbers); this can be worked around by assuming that the texture VRAM consumed is twice the amount of bound GL textures. Of course, you must make sure there is enough free RAM (physical RAM, and not virtual one which accounts for the swap space), else the OS (and especially Windows) will swap, and you will get very long freezes. The texture bias calculation algorithm must be made smart enough to avoid entering a yo-yo effect (bias increasing too fast, then textures getting blurry and memory getting massively released as a result, causing a bias excessive decrease and an immediate massive increase of textures memory consumption, etc): this became more likely to happen since the image decoding became multi-threaded (the textures decode so fast, that huge memory consumption variations can now happen in under a second, i.e. too fast for a discard bias readjustment to take effect).

This is most likely the result of the freezes, and not their cause (while frozen, the viewer cannot process the incoming packets and thus looses them).

It depends on what version of LL's viewer is used: the PBR viewer is sizing ”texture memory” dynamically... It does not hurt to try anyway, and might well at least solve the issue for FS... Also, the recommendations I made in the post I linked to (especially with regard to the swap file, which reallocations could incur such freezes) are no less valid...

Very similar to this issue (Windows, 16GB of RAM only, and a graphics card with lots of VRAM)... Try disabling the ”dynamic texture memory” setting (in the ”Preferences” floater, ”Graphics” tab, ”Hardware Settings” sub-tab), and set the ”Viewer Texture Memory Buffer” slider to 2048MB, and see what happens then...

Good question... Yet, it happens. I tried multi-threading with OpenJPEG v2.5, but it crashes when also using the multi-threaded image decoder (based on a LLThreadPool) in my viewer (maybe a pthread issue: not sure how the latter deals with sub-threads started from threads). So no, it was just one thread per decoded image, like I have now with v1.4.

That would be unpractical... It has been years I modified OpenJPEG v1.4 and, as usual, being the ana1 (*) programmer I am, I also modified the code formatting to something cleaner, meaning even with a simple 'diff', you'd get a large file, with irrelevant, formatting changes... It should be considered a fork now. Also, some changes that went info v2 would have to be actually reverted to get back the well-behaved/non-ugly rezzing experience of v1.4 (e.g. foliage rezzing is totally yuck with v2). I might try, time permitting, but I got more prominent work to do right now (EE/PBR dual-renderer, for example)... (*) With 1=l of course... Sometimes, this forum auto-chastising and auto-censoring ”feature” bothers me... We'd need to have it use an AI to avoid censoring jokes applying to self... 😝

You might want to have a look at the (heavily) patched OpenJPEG v1.4 version I am using in the Cool VL Viewer (libopenjpeg/ directory in the viewer sources): it also passes all the tests of Bug Island with the exception of those two textures (but it does not crash at least). It has got all the known security and crash bugs fixed, many personal micro-optimizations, SSE optimizations backported by me from OpenJPEG 2, a couple AVX opts by Kathrine Jansma, and it is well behaved while rezzing textures (e.g. the alpha channel is decoded early, avoiding pseudo-opaque textures while rezzing, like what happens with OpenJPEG v2). I recently tried (again) OpenJPEG 2 (v2.5 this time, with a patch for partial texture streams), but it fails many times where v1.4 succeeds, and rezzes textures in a ugly way (especially tree/foliage textures, quite a few of which don't even decode fully/properly). So I decided (once more) to keep the patched v1.4 for my viewer...

Nope... Uncheck ”Activer la mémoire de texture dynamique”, and instead use the slider above (that will get enabled) to set it (the maximum is already 2048MB, which will be fine).

Your computer memory is almost full... That's the problem (at this point, Windoze must be swapping like mad). What is the settings you are using in the viewer for the texture memory ? With only 16GB of RAM available, you should not use more than 2GB of texture VRAM or so (maybe up to 4GB, if you run the viewer alone), to avoid filling up your computer memory to the brim (for each texture held in VRAM, two copies, one ”raw” and one decoded, exist in RAM). You could also try the Cool VL Viewer and see how it fares on your system (I optimized it to properly size the texture memory to available RAM and VRAM, and keep everything in line). Also, you should configure Windows with a fixed size swap file, so to avoid seeing it reallocated each time Windows wants to grow it, causing freezes, slow downs or even crashes (Windows returns NULL pointers (out of memory condition) for malloc() calls, when they happen at the very moment it resizes its swap file, and programs do not like that...): a 8GB swap file should be more than enough. Here is where to set the swap file size:

When objects get removed from memory because you changed region, several things happen: The regions you left behind get disconnected and removed from memory. In all, but the Cool VL Viewer (which uses a staged removal, at a rate of one region removal per second), this is done in one go (all regions removed at once), which may incur a large ”hiccup” of dozens to hundreds of ms (one smaller hiccup per second and region for the Cool VL Viewer, until all regions are removed). The objects which were present in the removed regions got their data written to the object cache, on file (one file per region). In all, but the Cool VL Viewer (which uses a write thread for the objects cache), this is done synchronously by the main viewer thread, and incurs another ”hiccup” (from a few ms to a couple hundreds ms, depending on how many objects are written and how fast are your OS and disk). The objects in every removed regions are then removed from the objects list. Here again, it is done synchronously (by the main thread), and here again you can get a ”nice” hiccup for each region. The textures that were used by the removed objects and are no more used by newly rezzed objects get in their turn removed from the texture list: this is done progressively, a few seconds after the last usage of each texture, and as a result the memory gets freed (which may cause newly rezzed textures to get more space and be re-decoded at a higher level of detail), and the texture list gets smaller, which increases the speed of its periodic refresh, causing a progressive increase in the frame rate. To the above, you may (this is not systematic) also see other things happening as new objects rez in the region you entered (and possibly neighbor regions that just got connected): The texture cache may get full, and the viewer will then enter a cache cleanup (oldest cached textures will be removed until enough room is made in the cache). In all, but the Cool VL Viewer (which uses a fully threaded texture cache), this is done in either one big wipe (= large hiccup), or several small ones (= a few hiccups during a few seconds). The assets cache may get full, due to newly rezzed meshes. Normally, all viewers should now clean up that cache asynchronously (in a thread), but the resulting file I/O concurrency may still cause hiccups whenever the main viewer thread attempts a synchronous file access while your disk (or OS) I/O queues are saturated. There are also other sources of ”hiccups” while moving around on the grid (such as object cache reads on already visited regions connection, or slow DNS replies on region connection or on first access of an HTTP capability you just received from a rezzing region). This includes just ”turning around while staying in region”: objects also get removed from the objects lists (since no more in your camera FOV), textures removed later, caches possibly getting full with new meshes and textures being rezzed, depending on your position and draw distance, neighbor regions getting connected. It is alas not currently possible to remove all the hiccups (even if things could be improved, like I did with my viewer); with a threaded Vulkan renderer, however, we could well see those hiccups disappear in the future...

Should they remove it, yes... Rider Linden however hinted, during one of SUG meetings, that they used a stats gathering tool to see what services were still in use in SL, before extinguishing one... Conclusion: if you don't want this feature to fully vanish from SL, use viewers still implementing it, and use it yourself ! 😜 And to prepare the future, do support JIRA issues about that feature, so that LL simply adds the few lines of code necessary to transmit and update the skills/interests/web-url data in the existing capability (this is likely a trivial work to do, so all what LL needs is proper motivation resulting from a sufficient number of residents' requests).

There is already: BUG-233223 As a side note, the Cool VL Viewer still implements interests/skills/language and personal web site URL pages, while also using the new capability (with large 2nd life and 1st life texts support). I also improved the interests/skills presentation a tiny bit (when checked in others' profile, they do not any more appear with the hard to read disabled text color).

Or simpler: return the router as non-conforming to the seller, and ask for a refund. Such a lame implementation is unacceptable.