Size matters more than expected

[NaomiLocket]

Basically boils down to the algorithm being bunk the whole time and animat's observation is basically correct. It isn't possible for an LOD to cover a m2 area that is not displayed or one that it isn't rendered for. The prim equivalence doesn't exist also. And the data transferred is not increased in size, so the metric shouldn't be repurposed.  In the same way that a function should ideally be responsible for one thing, so too should the words and metrics used to describe an asset.

[animats]

On 4/28/2020 at 6:45 PM, Ardy Lay said:

SL uses CPU, then GPU, then CPU then GPU, etc. 

OpenGL is not synchronous like that. The CPU requests GPU operations, which go into a queue upon which the GPU works. If the CPU had to wait for every OpenGL call to complete, graphics would be much slower.

Some operations do stall the rendering pipeline. Alpha blending does, I think. Alpha blending requires that the objects be sorted and rendered in depth order. In SL, alpha blending is the default mode if there's an alpha channel. It's only useful for translucent objects and tends to be over-used. There should be a small LI penalty for turning it on, but there isn't.

[Ardy Lay]

3 hours ago, animats said:

OpenGL is not synchronous like that. The CPU requests GPU operations, which go into a queue upon which the GPU works. If the CPU had to wait for every OpenGL call to complete, graphics would be much slower.

Some operations do stall the rendering pipeline. Alpha blending does, I think. Alpha blending requires that the objects be sorted and rendered in depth order. In SL, alpha blending is the default mode if there's an alpha channel. It's only useful for translucent objects and tends to be over-used. There should be a small LI penalty for turning it on, but there isn't.

The render thread is indeed waiting on something while the gpu is working and the gpu is waiting while the render thread is working.  What would be your explanation for this?

[animats]

2 hours ago, Ardy Lay said:

The render thread is indeed waiting on something while the gpu is working and the gpu is waiting while the render thread is working.  What would be your explanation for this?

How can you tell?

Running SL on a reasonably decent graphics card, the main thread tends to use 100% of one CPU, while the GPU is probably under 50% utilized. There are points where the CPU does block waiting for the GPU, like at the end of a pass for lighting or shadows.

[Ardy Lay]

1 hour ago, animats said:

How can you tell?

Running SL on a reasonably decent graphics card, the main thread tends to use 100% of one CPU, while the GPU is probably under 50% utilized. There are points where the CPU does block waiting for the GPU, like at the end of a pass for lighting or shadows.

Some of the places I spend time are very built out and have 15 to 44 avatars visible in a short radius.  When I was building viewers I'd spend time using the performance profiling instrumentation in the build to see how many calls were made to routines and how long they were taking.

While I was doing that I noticed that some of the scenes were resulting in CPU time dropping off and frame rate slowing down.  I would then relog without the profiler and saw the same drop off.  CPU was using less power, CPU clock was still boosted but CPU was idle a lot more.  GPU utilization might be high or low at this time, depending on what is being rendered, I suppose.  When GPU utilization is low, GPU clock would slow down, making frame rate even lower.

I may try to find you a place to stand to witness this.  I got tired of trying to fix it, since I am not good with C++.  My gig was assembly language industrial controllers.  So I have started asking people questions about how it could be fixed.  The common answer is throw it out and start over.  😞

[Kyrah Abattoir]

That being said, one of the bottleneck is probably the sheer number of textures & meshs a typical sl scene is using.

I wish there was a clear way to see when it's just swapping back and forth from ram to vram constantly.