#SL Viewer Performance

Inara Prey recently wrote an article on Comparative Viewer Frame Rate performance. It is a handy reference. It took lots of effort to collect those numbers, which is why I seldom do rigorous tests.

Somewhat surprisingly it is the Linden Lab’s 3.2.5 viewer that is the fastest in the comparisons. I use the Development viewer 3.2.6, which is a little faster for me than 3.2.5.

The Lab’s viewers have not updated over the holidays. We may see some updates today or tomorrow. I suspect the Lindens are just getting back from the holidays and getting back into things. Also, it is a new year. People are fresh from a break and we may see some things change as they look at things with fresh eyes. Time will tell.

The main viewer is now 3.2.4. The beta version is 3.2.5. And the development viewer is 3.2.6.

The 3.2.6 is said to be the release with most of the Shining branch’s OpenGL fixes and changes for compatibility. I’ve been using a 3.2.6 version since December 12th (246465) with four updates; 246560, 246813, 246889, and now 246959. Of that series the 246959 version is the fastest, but not by much on my system.

Looking at the numbers Inara collected one can see some interesting oddities. I’ve added some percentages so I can see how much the viewers differ. The % Increase column is 1 – (Exodus FPS/SLV FPS). This tells me SLV is 3.51% faster than Exodus. The % Loss is 1 – (Deferred FPS/High FPS). This shows me how much performance was lost by turning on Deferred Rendering. I repeat this process as we move to the right so I can see the cost of Ambient Occlusion, Shadows, and Ambient + Shadows. The very last column is 1 – (High FPS/Ambient + Shadows FPS) to show the total loss.

Three viewers do faster shadows with Ambient Occlusion turned off… or at least that is what I take Inara’s table to say.

Comparison in Percents

Also Inara sees a consistent 50% ± loss of performance when using Deferred Render. I see about a 25% loss of performance when enabling Deferred Render. Inara also sees a 34% loss when enabling Ambient Occlusion. I see no loss in FPS when I enable it. With shadows she sees about 13% loss and I see about a 20% loss. While Inara looses about 21% with Ambient and Shadows I only lose about 8%. Her over all loss is from HIGH to ALL is 77% my over all loss is 31%.Deferred render is usually used to reduce geometry calculation for multiple lights. We saw the number of lights viewers handle go way up this summer. It is a shift from 10 or so to a couple of hundred. One of the complications from deferred render is alpha transparency. It gets extra complicated, which could explain why we saw alpha improve a bit then degrade once again when we got deferred render.

But where my FPS is 16 on High hers is 55. I have a better video card and she has a better CPU. Mine is Duo and hers is a Quad. Those features that can be handed off to the GPU cost me little performance and her quite a bit. But, the load on the CPU is holding me down. There could be other factors, but I think these two make the most difference.

It is also obvious that those viewers using the 3.2.2 Linden code are way slower than those using the 3.2.5 code. There is about a 27% boost moving to 3.2.5.

We know the Phoenix team does not currently have any render pipeline specialists. The only TPV team that may appears to be Exodus. But, Cool Viewer’s Henri may understand the render pipeline, I’m not sure. Others may too, but not that I’ve heard. So, our performance improvements will likely be coming from Linden Lab and appear first in the SL Viewers. This is significant for combat gamers. Especially since at ground level where most fighting happens the SL Viewer has a 20% advantage over Exodus… at least from Inara’s data. Different hardware will likely give different results. Inara’s is the best comparison data we have.

3 thoughts on “#SL Viewer Performance

  1. I think we can safely say that Henri understands the render pipeline pretty well after the way he managed to do what many thought was impossible and backported mesh rendering to the viewer 1 code-base.

    I did think that 3.2.5 had all the shining fixes in it, but unless you are a TPV dev it is difficult to say as the automatic code diff in the builds is still broken. One thing that is clear is that the last pre-mesh viewer (think that was 2.7) is still faster than the latest SL 3.2.6 dev viewer.

    • I was just reading Henri’s forum. In the announcements section he says “…I am not experienced enough in 3D renderers coding…”. Where he draws the line for ‘experienced’ may be a different place than where I’m thinking. But, I think that suggests optimizing the render pipeline is not an easy or quick thing for him.

      I agree he knows the viewer and programming. He also wrote a wonderfully precise post on the what is and is not a V1, 2 or 3 viewer and how many of us are confusing people with the terms V1, V2, or V3. Also, he is very clear on the future of V1 (or what most of think of as V1) viewers. See: http://sldev.free.fr/forum/viewtopic.php?f=5&t=584

      I think the Shining fixes are trickling forward as individual fixes making it through QA. When I’ve had a chance I’ve asked Runitai and his answers always seem a bit vague rather than precise just saying they are working through QA. I suspect he is working more on the fixes than closely following their advance through the pipeline, which makes sense to me… whether that’s real or not…

  2. Pingback: Comparative Viewer frame rates | Living in the Modem World

Leave a Reply

Your email address will not be published.