Day: October 30, 2021

The following notes are taken from the TPV Developer meeting held on Friday, October 29th, 2021.

These meetings are generally held every other week.  They are recorded by Pantera Północy, and her video of the meeting is embedded at the end of this report – my thanks to her for allowing me to do so – and it is used with the chat log from the meeting and my own audio recording to produce this summary, which focuses on the core topics discussed.

SL Viewer

This list gives the status for all currently available official viewers.

• Release viewer: version version 6.4.23.564172, formerly the Apple Notarisation Fix RC viewer, issued September 24 and promoted October 15.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • 360 Snapshot RC viewer, version 6.5.0.564863, issued October 21.
  • Maintenance RC viewer updated to version 6.5.0.564805, on October 20.
  • Simplified Cache RC viewer, version 6.4.23.562623, dated September 17, issued September 20.
• Project viewers:
  • Performance Improvements project viewer, version 6.4.23.564530, dated October 12.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Mesh Optimizer project viewer, version 6.4.23.562614, issued September 1.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

Apple Notarisation Viewer Issue

[Video: 26:10-27:38]

With the release of the Apple Notarisation Viewer there were updates to many of the viewer’s third party libraries, and some of these updates have be found to cause issues related to playback of certain media types in-world (notably MP3s and MP4s). A fix is in progress, and once ready, LL intend to fast track it through QA ahead of other viewer updates and make an RC viewer with the fix available ASAP.

However, for those wishing to avoid the issue, the following workarounds are offered:

• Windows:
  • Uninstall the Second Life viewer the usual way.
  • Navigate to your Program Files folder (Win 64-bit) or Program Files (x86) (Win 32-bit); locate and delete the “SecondLifeViewer” folder.
  • Download and install the Simplified Cache viewer (the previous release viewer).
• Apple Mac:
  • Remove the Apple Notarisation viewer from your system.
  • Download and install the Simplified Cache viewer (the previous release viewer).
  • Read the instructions on this page to work through any occurrences of unwanted notarisation warnings.

Viewer Performance Notes

[Video: 3:18-15:35]

As has been reported in these pages, the Lab is focusing on a range of performance improvements in both the viewer and on the back-end. In respect of the viewer, a new Performance Improvements project viewer has been released (linked to above. This prompted an update from Runitai Linden and Ptolemy Linden of the graphics team during the meeting:

• The core of the viewer work thus far has been on profiling and optimisation using the Tracy debugger.
• Results thus far are described as going “pretty well” with some systems / hardware and “not bearing much fruit” for others.
• The Lab are keen to get feedback from users for this viewer – particularly in comparing frame rates with the current official viewer release.
• However, the request for users to try the viewer come with the warning: it is known to suffer regular crashes, in part because LL have been playing “fast and loose” with settings, such as enabling OpenGL core profile, and also as a result of experimenting with moving some processes to background threads, etc., – although the overall effect of such thread moves is eventually to provide improved performance in stable viewers.
• Windows 32-bit and a version for Apple will be made available in due course. However, the Apple version is subject to frame rate issues associated with the Mac build being rectified.
• The availability of an external analysis tool that can be enabled during the viewer compile process means that a lot of the internal instrumentation within the viewer will likely be removed – notably around block timers, which can generate a lot of performance woes.

Upcoming Work

• Future work includes adding further threading capabilities:
  •  Nat Linden working on a generic project to try to unify all the various background threads into something that can pick-up any given task, removing the need for multiple threads effectively being “asleep” for much of the time, but taking up processing cycles.
  • Runitai is working on re-writing how rigged avatar attachments are handled. This is perhaps the most frame-intensive operation performed by the viewer in trying to draw them individually (none of the operations are batched).
    • Runitai is currently working on the fork of the render pipe inside the avatar draw pool that handles this work and move it to the same machinery that handles the other draw pools,. This should hopefully enable rigged mesh rendering to be handled on a batch basis, rather than one face at a time.
      • (There are some hurdles to overcome with this, such as texture changes; however, if the work is successful this could result in a substantial reduction in the number of draw calls the viewer has to perform with avatars+rigged mesh).
    • A degree of optimisation has already been carried out with rigged meshes (e.g. not re-uploading the matrix palette for every single face when it can be re-used which should help reduce draw calls; looking at the extra load placed on the viewer by making singletons thread safe, thus causing viewer locking, etc.).
  • OpenGL textures now have a dedicated thread and GL context (LLimageGL) for processing and then re-sync’d back to the main thread, which has resolved a lot of frame stalls. This working currently encompasses all fetched textures (sky rendering and media texture rendering is still bound to the main thread).
• Ptolemy Linden is looking into render frame stalls (e.g. due to some EEP calls getting into a loop and can cause stuttering in the viewer).
• Uniform buffer objects have also been looked at, but it requires a further tidy-up of other code within the rendering system (e.g. handling of EEP parameters) before any real results will become visible with this work.

Increasing the Default VRAM limit from 512 MB

• Runitai referred to the limit as misleading, as the system will use more VRAM where available, even with the limit set.
• LL have run into problems in low-end systems running out of memory if the value is increased (possibly because Intel don’t provide an API to provide information on actual VRAM usage), and so the request was put to TPVs who have solved this issue to consider supplying the Lab with a patch they could look at, it would be appreciated.

OpenGL Replacement

[Video: 15:36-16:43 and 35:00-38:35]

As has been noted in previous meeting summaries, Apple are deprecating OpenGL on their OS. This has prompted LL to look for alternative APIs.

• Runitai indicated that MoltenGL may be looked at specifically for Apple. This essentially provides many of the performance benefits of the Metal framework, while maintaining compliance with the OpenGL ES 2.0 API. However, any move towards this solution will require further evaluation, together with a better understanding of how possible licensing requirements might impact TPVs.
• Beyond this, all plans remain fluid. The options primarily under consideration are:
  • Using Vulkan (Windows) and Metal (Apple).
  • Running Vulkan extraction layers on top of G3D on Windows (and MoltenGL for Apple?)
  • Implementing an off-the-shelf multi-API extraction layer.
  • Home-brew a dedicated extraction layer.
  • Stick with OpenGL for Windows and use MoltenGL for Apple (as noted above).
  • Initially supporting Vulkan + OpenGL for Windows and then retiring OpenGL and running Vulkan extraction layers on top of G3D (no word on Apple solutions in this scenario)
• However, a consensus has yet to be reached on the direction to be taken, the focus is on furthering an clean-up of the rendering code and improving performance on OpenGL as far as possible, then consider making the move to alternatives.

Windows 11 and SL

[Video: 28:02-30:17]

• So far there do not appear to have been any significant issues encountered by LL  / users in using Second Life on Windows 11 as the latter is made more broadly available.
• There are a couple of reported minor issues:
  • BUG-231041 “[Windows 11] Memory creep running with Windows Insider Beta version, when Viewer is minimised”, which has apparently yet to be confirmed as an issue with the release version of Win 11.
  • The viewer reports the OS build as: Microsoft Windows 10 64-bit (Build 22000 [and above]).
• If anyone is encountering reproducible issues which appear to be tied to Windows 11, please file a Jira.

Update on Mobile Status

[Video: 32:45-33:52]

As has been reported elsewhere, work on the SL Mobile App for iOS has been suspended for the time being. Commenting on why and for how long, Mojo Linden (LL’s VP of Engineering) commented:

• LL is still “very interested in moving things forward in the mobile space”.
• The pause is liable to last “a number of weeks”.
• The hope is that following any review, the Lab will be bringing “bigger and better things to the table”, although the pause has also been due to the need to divert resources into other work.
• Not much more was said (in part because Mojo did not want to steal Grumpity Linden’s thunder), but there will be “more news in the future”.

In Brief

• [Video: 1:16-1:42] Chap Linden is the new Product Manager for the viewer, taking over from Alexa Linden. He has been with the Lab for around two weeks (at the time of writing), and his responsibilities may expand in time.
• [Video: 20:25-26:00] A general discussion on viewer build tools and simulator-side changes on the beta grid to ease viewer build testing.
• [Video: 43:32-42:50] LL is apparently dealing with an (allegedly) China-based website that has (or had) been using the Second Life name to illegally sell cryptocurrency.
• Kitty Barnett from the Catznip team hopes to be able to contribute her work on Linden Water occlusion (so “unseen” Linden Water is effectively ignored by the viewer, reducing the render load & improvement frame rates) to the Lab Soon™.