I'm not asking for an explanation of what's wrong. I'm asking them to refactor the client to bring it from 2002 to 2026. To get away from the massive single-threaded workload that makes traveling with high draw distance awful. That is the problem, not bus saturation.

They farmed out image decode and a few other things to worker threads, but they still have the meat of the rendering pipeline in one thread. Fixing that is a major overhaul. Not fixing it makes the experience jankier than it could be. The attached image shows about 70 milliseconds in ONE FRAME being spent almost entirely on CPU-bound logic, and that's only the parts they instrumented in the fast timers overlay. (Geo Update is almost entirely CPU, does talk to the GPU concerning trees/water/sky, but these are not significant factors.)

It's bad for me at high draw distance, and I have a 16-core CPU and an RTX 4070. Other people with older/slower machines have to run at very small draw distances, or throttle their network bandwidth severely.

Huns Valen One thing to take into account regarding the fast time window here is that, the fast timer code 1) isn't complete and 2) is broken, it remains an interesting tool, but it can't be read so strictly. As here you see the green part thinking "it's cpu", but it's not .. it's just the tool is missing some informations, some being processed by the cpu, some other by the gpu, and the more internal parts where a component is waiting for data. Linden people use an other set of tools to measure and analyse frames.

Now, it doesn't mean you are wrong about the underutilisation of the hardware. Thing is, cpu and gpu "utilisation" is what every game engine seeks to optimise, and there are many reasons in SL why it's more complicated to do it compared to other game engines, starting with the fact that in a more standard game, each scene is actually (normally) optimised by the developers, as they have the full control on what's going on: how complex the geometry will be, how much volume of textures would there be from certain point of view, how many light sources, which shaders will be used etc etc.. Linden Labs doesn't create the content, and let people being very free about it.

So when you push the draw distance in SL to 512m, specially on mainland, you will put any hardware on their knees, just because for reasons to determine case by case, it will cause a under-utilization of the hardware, synchronizations issues .. and so on. (also if you use shadows, it will get worse).

And for large draw distances, one major issue is also how the geometry (and textures) LOD is managed.

Last but not least: OpenGL doesn't allow some modern optimisations, specially when you deal with a lots of objects.

When you double the draw distance, the vision cone not only become deeper, but also becomes much larger, resulting to an important multiplication of the actual objects to process, that goes far beyond a simple X2 factor.

observeur Resident I don't necessarily disagree, but fundamentally the issue is that they're using a primarily single-threaded architecture to solve a problem that could be solved more effectively with multi-threading. The number of objects can theoretically scale on a curve approaching distance^3, but that doesn't change the underlying problem: it's just not as efficient as it could be regardless of draw distance or object density.

Huns Valen There is always ways to optimise, it's just, LL has a limited team and many subjects to cover. But, to be fair, performance has actually increased over time, specially with recent enough hardware (exception being, very old or very weak hardware). Now there is room for many other optimisations, and that includes this particular case where you use a long view distance in a messy place like Mainland, or any place with high density geometry. This implies different combined strategies, including a more "horizontal" approach, as better using multiple threads, maybe a more efficient objects culling strategy (this is specially important, since in your example, there are several buildings/houses, and you want the objects inside those houses to be properly and efficiently culled).. which is related to lod too, because if a house is lowered to a single triangle from a distance, then the objects inside the building will become potentially visible). But also by using a more modern graphics api. And they perfectly know it, and it has been mentioned several times in developers meetings.

One little tip that can help in different conditions: When using an nVidia gpu, you should make sure that "Multithreaded optimisations" is turned ON, in the (old) nVidia control panel, generally, or specifically for Second life.

This will tell the OpenGL driver to use its own internal optimisations, and this leads to important performance boost in different situations.

a couple things i observed in the area you mentioned:

performance is indeed pretty low with a 512 meters view distance, specially when enabling sun shadows.

1) this is not due to vram, because i tested it with a machine with 40gb of vram, and it doesn't help in this particular case.

2) this is not directly related to the cpu single core performance, as i also tested this with a much faster cpu than my gaming PC, without gain, i also used a lower CPU power mode in the PC, without any loss in performance.

3) this is not (much) related to the gpu performance either.

An other thing worth mentioning: if you raise the object lod setting in the graphics advanced settings (objects -> High), you won't see any loss in performance on recent enough hardware, such as yours.

most likely this is due to how objects are processed into exploitable data for the gpu. Maybe a high context switches rate also.

side note) enabling shadows in this scenario will divide the performance by 2, which is to be expected.

Toothless Draegonne I think they should try :)