Server Deployments: week 5 recap
- On Tuesday January 28th, the Main channel received the server maintenance project previously on the three RC channels, which contains a single fix for a crash mode.
- On Wednesday January 29th, all three RC channels received a new server maintenance project, which includes a crash mode fix and a fix for llModifyLand() modifying the wrong location in region, when called in a child prim – see part one of this report for further details.
SL Viewer Updates
The following notes are taken from the TPV Developer meeting of Friday January 31st, a video of which is included below. My thanks, as ever, to North for the latter.
Fitted Mesh
As noted in part one of this report, a new version of the Fitted Mesh viewer arrived in the release channel as an RC on Monday January 27th. Version 3.7.0.285669 includes a number of fixes, included a hoped-for resolution for FITMESH-6 and FITMESH-20. However, there is an issue with the fix, as reported by Latif Khalifa of the Singularity team, and which the Lab has confirmed. The viewer will therefore have a further RC update in week 6 (week commencing Monday 3rd February). If the new RC proves stable and reliable, then the Fitted Mesh viewer will be looked at as a contender to go to release status.
Interest List
Despite having been reported as having a much improved crash rate, the Interest List RC, version: 3.6.14.285213 released on January 14th, still appears to be reporting higher than expected crashes. The Lab is not 100% convinced the crash measurements are correct, and they may be measuring high. This is being poked at, but means in the interim the viewer will remain an RC.
HTTP Viewer
The HTTP RC viewer, version 3.6.14.285253 released on January 16th, is performing well and now stands as the strongest contender for the next promotion to the de facto release viewer.
Maintenance Viewer and GPU Table
The Maintenance viewer, version 3.6.14.285499 released on January 23rd has generated interest due to the inclusion of MAINT-3131 “Death to GPU Table”.
Essentially, the GPU table is used to define your graphics card to the viewer and the default graphics settings which are applied as a result when you first start the viewer. As many will be aware, the GPU table is manually maintained, and as a result is not a very effective mechanism for managing GPU evolution.
MAINT-3131 is part of ongoing work which the Lab hopes will eventually eliminate the GPU table. Discussing the work, Oz said:
The idea is to do two things: ask the [graphics] driver [on a local system] what version of OpenGL it supports, and use whatever capabilities that can be relied on to find that out; and then to measure the performance of the GPU by doing a series of memory bandwidth tests. Basically copying big blocks of video memory back and forth a few times and seeing how long it takes. The theory is that it ends up being at least as good a predictor of what the GPU is capable of as we’re currently getting by the guesses in the GPU table, and maybe better.
The code linked to MAINT-3131 is believed to be the code needed to carry out the memory bandwidth tests (and likely recording the results), the idea being that it can be monitored to note how well it measures the performance of things the Lab believe they understand, and see if it handles them more effectively / efficiently. Should this work proceed the way the Lab hopes, then the hope is the GPU table can be removed from the viewer in the future. It is thought that the bandwidth testing, which will likely only take place when or shortly after the viewer has launched (and then only after the GPU identifier string has changed), will be a “pretty good proxy” for measuring a GPU’s performance a GPU compared to just asking the OpenGL driver what it can do.
Continue reading “SL projects updates 5/2: viewer, GPU table, Rift, Leap Motion”