New Performance Viewer Build

[Alexa Linden]

Happy Friday! We've got a new Performance build out so give it a try! https://releasenotes.secondlife.com/viewer/6.6.0.571736.html… If you see any bugs, please file a https://jira.secondlife.com so we can take a look!

[bigmoe Whitfield]

5 hours ago, Alexa Linden said:

Happy Friday! We've got a new Performance build out so give it a try! https:// releasenotes.secondlife.com/viewer/6.6.0.5 71736.html … If you see any bugs, please file a https:// jira.secondlife.com so we can take a look!

yay! also I fixed the colour, as it's mashing with the darktheme.

[bigmoe Whitfield]

well I tried it,  whom ever has decided 128m default draw distance needs to think before implementing,  64m is fine for default,  landed on my last location which was mainland and instant system choke,  also things were not rezzing in around me,  people were, but not objects.   also still locked to 512mb vram, which is weird still why they have not merged code from the tpv's and pushed it, that's a heavy choke point.

[Coffee Pancake]

Apple M1 Mac.

Compared to Catznip R13.1 which does not have ANY of the linden performance changes, this viewer is a solid 5 fps faster and generally smoother. Excellent work LL !!

Can't wait to get these into Catznip

[Ardy Lay]

4 hours ago, bigmoe Whitfield said:

yay! also I fixed the colour, as it's mashing with the darktheme.

Moe, you broke it:

[bigmoe Whitfield]

1 hour ago, Ardy Lay said:

Moe, you broke it:

Oh bah!  lol okay.

[Phil Deakins]

I downloaded it earlier, not knowing that it majors in performance. I've been using the fastest viewer for some time - Alchemy. I downloaded the current release a few days ago and found that it is significantly slower than the previous one. Also, saving notecards and scripts when editing them was taking so long that I checked the grid status more than once yesterday.

It was no different today, so I opened the LL viewer to see if saving takes as long with it, or if the problem was at my end. In opening it, I had to download the latest version, and I was amazed at how much quicker it is than Alchemy. Alchemy now only gives me around 65-70 fps (it was a lot higher with the previous version), but the new LL viewer is giving me ~115 fps. What a difference! When I changed to Alchemy the numbers were totally the other way round.

So now I'll be using the LL viewer again - until more changes come along, perhaps

 

[Mollymews]

9 hours ago, Coffee Pancake said:

Compared to Catznip R13.1 which does not have ANY of the linden performance changes, this viewer is a solid 5 fps faster and generally smoother.

i did a quick comparison on Windows 11, GTX 1050Ti between Catznip R13.1 and Linden PI 6.6.0.5

with ALM and Shadows On then the gain is about 10% (4/40), which is about the same as between standard Linden and PI 6.6.0.5

with ALM Off then quite a lot (nearly 50% gain), which people with potato computers (pretty much where mine is at according to Windows 11 Update which says nah!) will be quite happy about

no idea what Linden have done exactly but I think will be quite a bit in it for TPVs dev to have a look into

PI 6.6.0.5 ALM Off.  105 about, up from 70 about

 

 

 

[Love Zhaoying]

4 hours ago, bigmoe Whitfield said:

Oh bah!  lol okay.

You can't please everyone. I'm with Team bigMoe!

[Henri Beauchamp]

43 minutes ago, Mollymews said:

no idea what Linden have done exactly

This is three-folds:

1.- Renderer improvements:

• The broken EE renderer occlusions have been fixed (especially water occlusions)
• The rigged mesh render passes have been made distinct from non-rigged passes in the draw pools and shaders; the code for the draw pools passes themselves has been simplified.
• The rigged meshes matrix is no more uploaded redundantly to the GPU (only once per mesh) and better rigged mesh bounding boxes determination has been achieved.
• A better render batching has been achieved.

2.- Threading additions:

• GL images creation has been threaded.
• Provision made for more threading (audio decoding is already in the pipeline: see SL-16182).

3.- Core GL profile compatibility:

• The few remnants of fixed OpenGL functions have been removed to make the viewer Core GL profile compliant.

 

In the above improvements, the most interesting one for NVIDIA cards owner is in fact the last one: enabling the core GL profile provides an enormous boost (50% or more FPS) to NVIDIA drivers/GPUs (which are already much faster than AMD's for OpenGL loads in compatibility profile).

The improved renderer provides benefits in venues with lots of avatars around (rigged mesh rendering speed improvements), but also for scenes with lots of alphas (better batching).

Then, the threaded image creation provides a nice benefit during rezzing (better and smoother FPS rate).

 

Quote

but I think will be quite a bit in it for TPVs dev to have a look into

Already part of the Cool VL Viewer v1.29.0 experimental branch, with additional fixes to LL's code.

Edited May 14, 2022 by Henri Beauchamp

[Jackson Redstar]

The primary issue I always see is rendering Avis - and details. With what I do, I am often surround by alot of Avis while filming, and also, (using Firestorm) I need to have Dynamic LOD set to off. Viewers like Alechemy just crank up dynamic LOD to make it seem like they are faster but in reality when set up the same to other viewers are no better. But the biggest issue is always Avis and how it kills FPS. Turning Avis into stick figures "works" unless you are trying to film a scene - or even enjoying being at an event with other normal 'people' all around. FS latest effort to improve FPS is more or less just centered around impostering avis around you. Im going to try out this new and improved Liden viewer see if it is better, but, unfortunately, the official viewer simply in not any good for machinima use

[Ardy Lay]

One thing I have seen is attached prims and link-sets that are scripted to move no longer have their movements visibly interpolated.  What I am accustomed to is when a script makes prim ears move from one position and rotation to another position and rotation, they move like they have some mass and the resulting inertia, resulting in a nice smooth motion from a single function call.  With this performance viewer, prim ears abruptly move with no visible interpolation.  This is a visibly jarring change.  I am looking now and see this in more than just my own attachments.  I see this abrupt motion in the attachments on other people's avatars too.

In contrast, scripted objects placed in-world do still exhibit this interpolated motion resulting in a nice smooth move from one position or rotation to another.

(This post transcribed to bug report at BUG-232137 .)

 

[ST33LDI9ITAL]

Just curious but since you are working on improving image decoding have you considered HTJ2K?

Edited May 14, 2022 by ST33LDI9ITAL

[Gavin Hird]

I have tested it on a Mac with the Apple M1 processor and 8 GPU cores and it is faster than the current default viewer. 

However, at the same scene, with settings as close as possible between the two viewers on the same machine, where the SL PerfViewer renders at about 57 fps, my Dayturn build renders at about 82 fps. I have to check if the difference is the same on an Intel based Mac...

Intel base Mac (3,8 GHz 8-Core Intel Core i7, AMD Radeon Pro 5500 XT 8 GB) the SL PerfViewer renders at about 61 fps, my Dayturn build renders at 71 fps. (The Intel based machine has a 5k display at 5120x2880, whereas the Mac with the M1 has a 2560x1440 display).

Both tests are done in a 1680x1050 window rendered at Retina resolution which makes the rendered resolution 3360x2100.

Edited May 14, 2022 by Gavin Hird

[Phil Deakins]

22 hours ago, Henri Beauchamp said:

Already part of the Cool VL Viewer v1.29.0 experimental branch, with additional fixes to LL's code.

I have to post this. When I read Henri's post, I tried the Cool VL Viewer (I already had it), and I was astonished that it's giving me FPS that the others can only dream of. ~150 with the standard skin and, surprisingly ~175/180 with the dark skin. Dunno why the skin should make such a difference but it does. I'm absolutely gobsmacked! I'll get the one in the quote but I don't think I need to.

I should say that the FPS numbers that I've posted in this thread are on a platform at 4000+ meters, with objects around but no other avatars, and graphics at High.

Edited May 15, 2022 by Phil Deakins

[Gavin Hird]

24 minutes ago, Phil Deakins said:

I have to post this. When I read Henri's post, I tried the Cool VL Viewer (I already had it), and I was astonished that it's giving me FPS that the others can only dream of. ~150 with the standard skin and, surprisingly ~175/180 with the dark skin. Dunno why the skin should make such a difference but it does. I'm absolutely gobsmacked! I'll get the one in the quote but I don't think I need to.

I should say that the FPS numbers that I've posted in this thread are on a platform at 4000+ meters, with objects around but no other avatars, and graphics at High.

I find that the FPS counter on the  Cool VL Viewer varies wildly in the same scene from way too low to spiking optimistically high, so I am not sure how to interpret it. (It might be the Mac version that behaves this way.)

[Phil Deakins]

6 minutes ago, Gavin Hird said:

I find that the FPS counter on the  Cool VL Viewer varies wildly in the same scene from way too low to spiking optimistically high, so I am not sure how to interpret it. (It might be the Mac version that behaves this way.)

I'm trying it. It seems to behave very quickly though.

I've found one bug (viewer closes down when multiple scripts are selected to open), but I'm not using the one that Henri linked to, so I'll try that to see if the bug still exists before reporting it.

[Henri Beauchamp]

1 hour ago, Phil Deakins said:

I have to post this. When I read Henri's post, I tried the Cool VL Viewer (I already had it), and I was astonished that it's giving me FPS that the others can only dream of. 

Fun fact: for literally years the Cool VL Viewer has been handicapped by a one-liner glFinish() call in LLWindow[SDL/Win32] (i.e. macOS builds were not affected), which was an ancient (antediluvian) remnant of the v1 code used in Snowglobe... While using glFinish() at the end of each frame was a good idea in the past, it nowadays totally kills the frame rate with modern GPUs/drivers. Yet, all these years, the Cool VL Viewer remained one of the fastest viewers around (the number of C++ optimizations I made and that piled up over years allowed this).

With LL's performance viewer, I ran tests against my viewer to see how they would compare (test done under Windows only, sadly, since LL is not providing a Linux viewer despite the excellent work done by Nicky Dasmijn on LL's viewer code base to allow compiling it for Linux; shame on LL !). Before the perf viewer (and despite its, to date, undiscovered handicap), my viewer was always beating hands down LL's viewer, but things changed suddenly with the perf viewer which equaled mine in compatibility profile and did beat it by 50% or more in core GL profile. The fact that I did not see any difference when switching core GL profile in my viewer was a clear sign that something was wrong. I then feverishly searched and scanned the code, until I fell on this silly glFinish() that was absent from all other viewers' code !

Removing that glFinish() immediately improved the performance in compatibility profile mode by 20 to 50%, depending on the rendered scene (this too, applies to other GPU brands than NVIDIA), and did unleash the core GL profile power on NVIDIA GPUs.

Now (at last), the Cool VL Viewer shows off all the optimizations that went into it for the past 15 years. Note that this also applies to the current stable branch (v1.28.2) that still uses the (switchable) legacy WL and the ”old” (non-perf) EE renderers.

Edited May 15, 2022 by Henri Beauchamp

[Henri Beauchamp]

38 minutes ago, Gavin Hird said:

I find that the FPS counter on the  Cool VL Viewer varies wildly in the same scene from way too low to spiking optimistically high, so I am not sure how to interpret it. (It might be the Mac version that behaves this way.)

Do not expect miracles with the Cool VL Viewer under macOS: I do not own a Mac, so I cannot test my viewer on, and much less optimize it for macOS... Also, the experimental branch currently got a crash bug on exit that only happens on macOS (*).

Finally, since I am not the macOS builder for Cool VL Viewer releases (Catten Carter has taken up this burden; thanks and kudos to him !), the macOS builds often lag behind Linux and Windows builds.

This said you can perfectly build the viewer yourself under macOS (detailed instructions to build the viewer, under all three OSes, are given in the sources doc/ sub-directory).

 

(*) If any macOS expert could diagnose this crash bug (apparently a destroyed mutex that gets reused by macOS in late (post viewer-code-cleanup) exit code), I would be extremely grateful !

Edited May 15, 2022 by Henri Beauchamp

[Gavin Hird]

23 minutes ago, Henri Beauchamp said:

Do not expect miracles with the Cool VL Viewer under macOS: I do not own a Mac, so I cannot test my viewer on, and much less optimize it for macOS... Also, the experimental branch currently got a crash bug on exit that only happens on macOS (*).

Finally, since I am not the macOS builder for Cool VL Viewer releases (Catten Carter has taken up this burden; thanks and kudos to him !), the macOS builds often lag behind Linux and Windows builds.

This said you can perfectly build the viewer yourself under macOS (detailed instructions to build the viewer, under all three OSes, are given in the sources doc/ sub-directory).

 

(*) If any macOS expert could diagnose this crash bug (apparently a destroyed mutex that gets reused by macOS in late (post viewer-code-cleanup) exit code), I would be extremely grateful !

Your viewer does not build with Xcode 13.3.1, so no, I can't build it.

To your bug, it is pointless to try and analyze it before the viewer is built with a deployment target that force you to remove all the old memory management code from the viewer, like I have done in mine (all those changes are in the Objective-C code). 

Then next, make it build with Xcode 13.1.x which will flesh out more deprecations which needs to be sorted. If the bug still persist, then run Xcode analyze on the viewer and see it if will identify the cause of the crash (there are 10s of occurrences of similar conditions; memory is read after being released in the viewer code). By that time you might be good. – I do not see that crash, and but I have only taken a portion of the PerfViewer code, so it can of course have been introduced in the commits I have not taken. 

The repository is here.

Xcode 13.3 only runs on macOS 12.3.x so that may not even be possible if you have a Hackintosh. 

Edited May 15, 2022 by Gavin Hird

[Henri Beauchamp]

2 minutes ago, Gavin Hird said:

Your viewer does not build with Xcode 13.3.1, so no, I can't build it.

To your bug, it is pointless to try and analyze it before the viewer is built with a deployment target that force you to remove all the old memory management code from the viewer, like I have done in mine (all those changes are in the Objective-C code). 

Then next, make it build with Xcode 13.1.x which will flesh out more deprecations which needs to be sorted. If the bug still persist, then run Xcode analyze on the viewer and see it if will identify the cause of the crash (there are 10s of occurrences of similar conditions; memory is read after being released in the viewer code). By that time you might be good. – I do not see that crash, and while I have only taken a portion of the PerfViewer code, so it can of course have been introduced in the commits I have not taken. 

The repository is here.

Xcode 13.3 only runs on macOS 12.3.x so that may not even be possible if you have a Hackintosh. 

Well, I could build my viewer on a Hackintosh VirtualBox VM running Catalina and (an early version of) Xcode 13...

But I propose that we take this discussion to the Cool VL Viewer forum since it is becoming rather off-topic here... Alternatively, use my email (sldev(at)free(dot)fr).

I am of course interested in any patch or commit you would have done to LL's code base to remove old macOS cruft and make it compatible with newer Xcode versions...

[Gavin Hird]

26 minutes ago, Henri Beauchamp said:

Well, I could build my viewer on a Hackintosh VirtualBox VM running Catalina and (an early version of) Xcode 13...

But I propose that we take this discussion to the Cool VL Viewer forum since it is becoming rather off-topic here... Alternatively, use my email (sldev(at)free(dot)fr).

I am of course interested in any patch or commit you would have done to LL's code base to remove old macOS cruft and make it compatible with newer Xcode versions...

Apple made a change with Xcode 13.3 which made it only run on macOS 12.3 or higher which is a real PITA. It is required for properly signing the viewer.

All the changes are in the repro.

Clone it and start at the commit DAYTW-32 Fix up the Objective-C code... applied 20 jan 2022. That is a summary of a number of commits applied to the Opensim version over time. From then on and forward pick the ones you want. 

DAYTW-36 from May 12 2022 might also be of particular interest

 

The Opensim version repo is on Bitbucket and has many of the same changes, but not all, as the new repo will be the new Opensim version. The new repo will also be on Bitbucket soon.

I have no intention of releasing a regular SL version as that would compete with Kokua, and we agreed to the split back in 2016. There is the preview that is SL compatible that runs on both macOS and 64-bit Win.

Edited May 15, 2022 by Gavin Hird

[Phil Deakins]

I installed the latest stable version of the Cool VL Viewer and I'm utterly astonished. It's quite unbelievable. The bug I mentioned is still there so I'll report it, but my FPS has gone up even further to 200-220 FPS! I'm not going to bother trying the Experimental Branch viewer that was mentioned.

I'm at 4000+ meters high, with some objects around but no other avatars. My graphics is set to High and my draw distance is set to 96m. I've no idea how the viewer will perform on the ground with avatars around but, since it's rare that I'm in such an environment, I won't bother trying it.

 

Edited May 15, 2022 by Phil Deakins

[Alexa Linden]

Happy Wednesday all! We have a fresh build of the performance Improvements viewer! Thank you to all of you who are jumping in and testing and helping find bugs!  https://releasenotes.secondlife.com/viewer/6.6.0.571869.html

[Paulsian]

very nice, is there a way to disable the auto updater. everytime I try a viewer that is not default I get popup preventing me from logging in forces installation to the default viewer, sometimes happens so quick I dont have enough time to pick my rez location and press login. Maybe a debug setting?