SecondLife tech myths

[Love Zhaoying]

11 minutes ago, animats said:

There are tools for finding out what's really going on.

Putting a microscope on a slow frame in Sharpview's rendering library, Rend3/WGPU.

This is a tool called Tracy. You can record several minutes of activity, and then zoom in on the log down to the nanosecond level. The line at the top shows how long each frame took. You can pan and zoom and see in detail what happened in each frame. You can build the SL viewer with this level of tracing enabled. It will slow down by a few percent.

Unless you're doing viewer development, you probably don't want this level of detail. The point here is that performance issues are not forever mysterious and un-knowable. There are ways to find out.

* Someone who reads your post and is clueless * :  "I guess the world will never know."

I like that the tool is called "Tracy", as in "Dick Tracy"!

[animats]

A useful way to think about the problem is this. The viewer has four main jobs that use substantial time.

1. Drawing the frames
2. Handling movement interpolation between frames.
3. Receiving updates from the network and acting on them.
4. Fetching assets.

Classic SL viewers do all this in one thread. #4 has been moved out to other threads in some viewers. There's a "coroutine" system, or what would today be called "async", but it only uses one CPU. So the normal situation is one compute bound thread, with 1), 2), and 3) contending for time. This works amazingly well, considering the constraints. There are lots of little algorithms in the classic viewers trying to load-balance those tasks.

In Sharpview, all four of those tasks are done in different threads, so we can get multiple CPUs working on the problem. It then becomes much clearer who's falling behind. This isn't magic. It requires substantial inter-thread coordination, and introduces new problems. There are lock contention problems, where two threads need to manipulate some shared item. The goal is to prevent the drawing thread from waiting for the other threads. That's not the only problem. I've had troubles with the movement thread falling behind. This shows up as high frame rate but jittery movement. Enough is now working in Sharpview that I can start to work on such performance issues.

Eventually, if and when LL switches to Vulkan, the C++ viewers might, someday, be updated to work that way. It won't be easy. Vulkan lets you change the contents of the GPU while rendering is in progress. All the levels above Vulkan have to cooperate to make that useful. Graphics systems which have been through that conversion took years of work by large teams to do it. May not be feasible as a retrofit. The rendering stack I use (Rend3/WGPU/Vulkan) just went through that, and it took most of a year. Converting Unity over was reportedly a huge effort.

I wonder how the mobile viewer does it.

[animats]

11 minutes ago, Love Zhaoying said:

* Someone who reads your post and is clueless * :  "I guess the world will never know."

Users should not need to know this stuff. It should Just Work.

I'm impressed with how well the single-thread viewers cope with overload. It's technology from the early 2000s, before everybody had lots of CPUs, but it's good technology from that era. The people who architected this thing were really good.

You can build the SL viewer from source with Tracy tracing enabled, if you want. It's a build option. Then you can run the Tracy profiler while the viewer is running and capture this data. Firestorm can also be built that way.

[Love Zhaoying]

1 minute ago, animats said:

Users should not need to know this stuff. It should Just Work.

For awhile years ago, Microsoft used the official term "IJW - It Just Works" to describe their interop between C++ managed/unmanaged code.

I think they should have copyrighted "IJW".

[Henri Beauchamp]

21 minutes ago, animats said:

You can build the SL viewer from source with Tracy tracing enabled, if you want. It's a build option. Then you can run the Tracy profiler while the viewer is running and capture this data. Firestorm can also be built that way.

So can the Cool VL Viewer. Eg, under Linux: cd linden/;./linux-build.sh --tracy

The Tracy profiler is then started on demand from the Advanced -> Consoles menu, or CTRL SHIFT 8

Edited January 4 by Henri Beauchamp