Server Deployments Week 33
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
- As noted in part 1 of this report, there was no deployment to the Main channel in week 33, as a result of the “grey box” attachment issue appearing in the week 32 BlueSteel deployment
- The Magnum RC channel remained on SSA, with no other updates
- The LeTigre RC received a new server maintenance package with “under the hood changes” which should not be visible / perceptible to users. This package saw the removal of SSA from LeTigre – Caleb Linden apologised at the Server Beta meeting for the confusion this caused as the forum thread & release notes did not initially make it clear
- The BlueSteel RC received further updates to the fixes released in week 32 and the fix for the “grey box” attachment issue
Viewer Updates
The CHUI RC viewer updated to release 3.6.3.279849 on August 15th (download & release notes). The Materials project viewer also underwent a further update to release 3.6.3.279904 on August 16 (download & release notes).
Server-side Appearance
As noted above, SSA is currently only enabled on Magnum for the time being. A decision will be made on Monday August 19th on server-side updates and deployments, and until then the Lab is keeping quiet as to what may or may not happen in terms of SSA enabling. However, from comments passed in recent discussions and a hint in the forum deployment thread, it would appear that if the data obtained from Magnum during the week remains solid, SSA might be considered ready for “prime time” in week 34.
The removal of SSA from LeTigre did cause some confusion, with at least one JIRA (SUN-109) being raised as a result. Given the JIRA refers to the slowness of avatar rendering, rather than to any overall failures (which shouldn’t happen anyway, given the viewer code is currently backwards compatible with the “old” avatar baking service), this tends to point to the fact that the rapid nature of SSA baking is being appreciated.
Group Ban list
“Group bans are coming along pretty well,” Baker Linden informed his ‘Thursday after meeting class’. He went on:
I chose to take the rest of this week to improve the code rather than continue progressing. I really hated copying an entire source file without trying to refactor it … So now it’s refactoring, cleaning up, and after that the viewer will be finished. Well, I need to add the functionality to some other subsystems and have it actually send an HTTP message but that stuff is all stubbed in anyway.
Some of the cleaning up work apparently involves removing the, umm, colourful metaphors he used when first commenting on the code to highlight those bits he wanted to poke about at. These have apparently been causing a few giggles among those able to peek into the repository!
Given the work is still ongoing, there is no ETA for a project or beta viewer as yet, and this may be delayed a little more while Baker considers the problem of group chat.
Because of the way in which group chat works, anyone who is removed from a group while they have the group chat window open is actually able to continue chatting / spamming within the group until they close the group chat window, unless the group moderator remembers to block them from chat first. This hadn’t been on Baker’s radar, and he’s going to take a look around and see what can / needs to be done to try to make sure the group ban function won’t suffer this weakness, if possible.
Other Bits
Textures Issues / Texture Thrashing
As reported in week 30, people have been experiencing texture load issues recently.
One of the more common problems is that of texture thrashing. This is when object textures seem to be constantly reloading and going from blurred to rendered to blurred. It is particularly noticeable on systems where the virtual address space is filling up and / or graphics VRAM (on older graphics cards) is getting filled, resulting in texture being “discarded” (if you suffer from the problem, you may have seen one or more “# textures discarded” messages on your screen).
The discards refer to the resolution at which the textures are being rendered (0 means full resolution, 1 means half resolution, and so on). As memory / address space is used, so the discard level rises and textures appear more and more blurred. Then, as memory use decreases as a result of the discards, the textures start to render correctly, using more memory and the discards resume, repeating the cycle.
A number of JIRA have been raised on the issue under the BUG (non-public) project, but Firestorm have an open JIRA on the issue, which can be perused (FIRE-10994).
A further problem which is being reported is that textures are failing to maintain focus from far to near (MATBUG-355), resulting in a similar blurring / clearing / blurring issue, and which may be related to a caching issue.
Fingers are being pointed to the root cause of the issues being somewhere in the viewer code; the Firestorm team, for example have found that in swapping back to pre-SSA viewers, the issues seem to vanish. Whether this actually means the problem lies within the SSA code, however, is questionable; there have been a good number of changes to the viewer’s rendering code of late, so this makes singling-out a cause difficult.
One of the problems in trying to pin-down any root cause is that older versions of the official viewer cannot be easily tested due to the way the mandatory updates are forced on users. Another issue is that the problems are sporadic inasmuch as someone appears to either have them, or they don’t (I’ve yet to encounter them, for example, on any V3-syle viewer I use). However, if you are experiencing the problem, please ensure you do raise a JIRA and provide relevant log files – whether or not the JIRA is public, it is the only way to be sure someone at the Lab is picking-up on these kinds of problems.
In the meantime, Whirly Fizzle has suggested some workarounds:
- Enabling texture compression can help ease the problem, as can lowering the texture memory buffer can also help
- Disabling VBO can help with memory bloat, although at a cost of FPS
- Make sure you don’t have TextureLoadFullRes (debug) set to TRUE (as apparently recommended by some content creators)
- If you’re on Firestorm, try setting FSDestroyGLTexturesImmediately to TRUE.
Inara Pey: Living in a Modemworld 
WHen is Linden Labs increaseing the max amount the viewer can use as texture memory. Im stuck on 512MB. but 768 or maby 1024MB would be intressting to test and use (i have 2GB)
LikeLike
It would make sense, if the Viewer can sense how much RAM the video card has, to allow a higher limit. I don’t have that much RAM. I used to be able to do this sort of stuff in my head: I’m wondering is there’s some bit-size limit coming in here, but it doesn’t quite look right.
Hypothesis: this would need 64-bit viewer code.
LikeLike
I am becoming increasingly convinced that, while some TPVs allow huge caches on disk, the underlying Linden code for controlling the cache, choosing what stuff to delete, and so forth, is inadequate for a large cache. Is too-large a disk cache a wasted effort? Places I visit regularly are often not cached, even though filling the cache would would take several days of full-throttle downloading. I know it isn’t that simple, but it doesn’t feel right.
LikeLike