please LL put developing a multi threaded SL viewer on your roadmap.

[DNArt]

Hello all.

 

I have been looking into ways to improve fps and general SL performance, probably like most of us did at some point in time. 

Of Course i did read many useful tips (thanks) but I learned the giant and overall bottleneck is our single core viewer. 

My PC sleeps when running SL at its highest settings and it can easily run multiple viewers without a huge drop in frame rates. 

I know I dont have the general hardware with 16 cores    BUT  it's not hard to imagine how much faster SL could run if more cores were used.  I'm guessing 4+ times in my case. 

Multi cores have been around on midrange and low end PCs for decades and I'm unsure if you even can get a single core PC these days. 

The trend in CPU's  is still towards more and more cores.    

So it's likely that at some point in the future LL will realise making a multi threaded version of their viewer is a must to keep their game running at acceptable frame rates.

For everyone with a gaming computer it feels ancient for many years already and today's gaming PC are tomorrow's mobiles.

 

Soo why not start development towards a multi threaded viewer now instead of 10 years down the road? 

Sansar no longer eats the lindens, that we happily  pay for playing our beloved SL,  please give the users something that surely will make all of us happy, even those with the 10+ year old multi core PC and laptop, it will have to get done at some point in the future anyway.    

I understood this is no trivial amount of work at all so I would expect multiple years and not months. 

But in my eyes that just gives more incentive to start working on this  A.S.A.P.   

[MarissaOrloff]

I'm sure they have has that discussion many times. Better would be to do that to SL server first to split off the simulation and physics engine their own individual threads so walking around in heavily loaded regions will not feel like being "Suspended in Gaffa" (thank you Kate Bush!).

 

[panterapolnocy]

You may want to check https://modemworld.me/2021/01/23/2021-tpvd-meetings-week-3-summary/

Quote

[16:32-34::45] The meeting saw a significant amount of text chat concerning the technicalities of viewer CPU / CPU core usage, TPV work in trying to rebuild viewer threading, etc. As this is text-based (and may not be of relevance to many users), please refer to the video from around the 16m 32s mark through to.

 

Edited January 25, 2021 by panterapolnocy

[MarissaOrloff]

On 1/25/2021 at 7:48 AM, panterapolnocy said:

You may want to check.....

 

Hey thanks for the link! Unrelated but I have that blue AMD issue on my iMac in bootcamp!

Edited January 27, 2021 by MarissaOrloff

[bigmoe Whitfield]

On 1/24/2021 at 1:29 PM, DNArt said:

Hello all.

 

I have been looking into ways to improve fps and general SL performance, probably like most of us did at some point in time. 

Of Course i did read many useful tips (thanks) but I learned the giant and overall bottleneck is our single core viewer. 

My PC sleeps when running SL at its highest settings and it can easily run multiple viewers without a huge drop in frame rates. 

I know I dont have the general hardware with 16 cores    BUT  it's not hard to imagine how much faster SL could run if more cores were used.  I'm guessing 4+ times in my case. 

Multi cores have been around on midrange and low end PCs for decades and I'm unsure if you even can get a single core PC these days. 

The trend in CPU's  is still towards more and more cores.    

So it's likely that at some point in the future LL will realise making a multi threaded version of their viewer is a must to keep their game running at acceptable frame rates.

For everyone with a gaming computer it feels ancient for many years already and today's gaming PC are tomorrow's mobiles.

 

Soo why not start development towards a multi threaded viewer now instead of 10 years down the road? 

Sansar no longer eats the lindens, that we happily  pay for playing our beloved SL,  please give the users something that surely will make all of us happy, even those with the 10+ year old multi core PC and laptop, it will have to get done at some point in the future anyway.    

I understood this is no trivial amount of work at all so I would expect multiple years and not months. 

But in my eyes that just gives more incentive to start working on this  A.S.A.P.   

change the font to white so we can read it.

[Flea Yatsenko]

Multithreading and Vulkan has been brought up a lot before. IIRC there is a problem where network fetching or something causes a single thread bottleneck. It was something unique to SL having to fetch things off the network. It's in this thread, specifically this post:

LL would basically have to re-write the engine, but they'd still be held back by the existing content, like using normal and specularity instead of PBR, not including massively unoptimized content that people have created. And the content on SL is the most valuable part of the platform, we've seen lots of technically superior versions of SL come and go, because they don't have the content and stuff to buy that SL has. I feel like a lot of people take for granted you can go to the marketplace and buy pretty much anything you want. It's there. It's amazing. LL built a fantastic ecosystem. But it takes a long time to build such a good ecosystem and the server and viewer software show its age. It would be a very huge undertaking to make SL multi-threaded. But x86 CPUs are done getting much faster per core and are just adding more cores.

A large part of optimization with SL comes from not being able to prepare the world. In a regular game, everything is set in stone and it's optimized assuming nothing will change. So you can take short cuts and make it run better. SL is all off the network, and it's always changing.

[Ardy Lay]

3 hours ago, Flea Yatsenko said:

LL would basically have to re-write the engine, but they'd still be held back by the existing content, like using normal and specularity instead of PBR, not including massively unoptimized content that people have created. And the content on SL is the most valuable part of the platform, we've seen lots of technically superior versions of SL come and go, because they don't have the content and stuff to buy that SL has. I feel like a lot of people take for granted you can go to the marketplace and buy pretty much anything you want. It's there. It's amazing. LL built a fantastic ecosystem. But it takes a long time to build such a good ecosystem and the server and viewer software show its age. It would be a very huge undertaking to make SL multi-threaded. But x86 CPUs are done getting much faster per core and are just adding more cores.

A large part of optimization with SL comes from not being able to prepare the world. In a regular game, everything is set in stone and it's optimized assuming nothing will change. So you can take short cuts and make it run better. SL is all off the network, and it's always changing.

I agree this is going to be challenging to reconcile.  Would there be any way to build a content processing workflow that can optimize an item for rendering then store the optimized version as an online asset for use by everybody that encounters the original in-world?

Edited January 30, 2021 by Ardy Lay

[DNArt]

Thank you all for your reactions. 

@MarissaOrloff good idea and  yes working on the server will surely help to do i have no idea how more performance there would cost LL in fees to Amazon.

@panterapolnocy  thank you for the link that was useful and enlightening to watch.   

@Flea Yatsenko  @  Ardy Lay i always wondered if some user selected (use a new flag) objects couldn't get compiled and optimized (for instance during a sim restart) to help with proper occlusion and faster rendering.

 

Watching the video of the meeting did convince me even more that they for now still give priority to other topics than rewriting the engine from the ground up as would be needed for proper multi threading.  Currently firestorm on 4k and ultra peaks at 7.5% of my CPU and the max load on my CPU is around 50%.  even when framerates go down under 10fps my computer is left to sleep. It simply uses to view cores.  The way things are going i don't see those issues addressed. And as a user I feel powerless to help the viewer go faster since its practically useless to buy faster hardware. 

SL did grow rapidly in years when it made all computers fry there graphics cards and CPU. How wonderful it would be if the viewer would just use the power we have available right now.  My network doesn't even know its being used and yet i have to wait minutes before grey textures show a picture.     The gab between available computer power and SL performance will only grow and grow making SL feel like a badly programmed game to most newcomers with a reasonable Computer. 

Rebuilding the engine for multi treading is a mayor (years ) undertaking so that decision has to be taken at the top.  LL doesn't seem to be jumping from joy to start doing that. 

I don't see any reason why switching to PBR would brake the current content in a very serious way . The defuse map and normal map would still be used and al do i do use the specular map most of the times .. it doesn't have a mind-blowing effect since no proper environment reflections are rendered anyway so taking the grey value would work i guess.  And speaking of shader's maybe the switch to Vulcan could give us several new shaders?  Like a ground shader available for mesh and some thing to keep the water out of our boats.    

   

    

[Nalates Urriah]

Multi-threading is part of the update effort when anything in the system is updated. The render engine is the part most in need of it. It is also the most difficult to update and I suspect the OpenGL engine will eventually be replaced.

 

[Mollymews]

Linden have sort of started with this

the latest Second Life Release 6.4.13.555871 (64bit) separates out UI rendering from the world viewport rendering

in general I find that there is not quantums difference but is a start

Edited February 20, 2021 by Mollymews
nois

[Wulfie Reanimator]

4 minutes ago, Mollymews said:

Linden have sort of started with this

the latest Second Life Release 6.4.13.555871 (64bit) separates out UI rendering from the world viewport rendering

in general I find that there is not quantums difference but is a start

Any effort that goes into untangling your spaghetti is never wasted.

[Kathrine Jansma]

You can throw a few more threads at the viewer and it actually helps, but not directly for fps...

Have a look at the latest version of the Cool VL Viewer, it uses a thread pool for texture decoding, which improves rezzing speed massively.

 

 

[animats]

2 hours ago, Kathrine Jansma said:

Have a look at the latest version of the Cool VL Viewer, it uses a thread pool for texture decoding, which improves rezzing speed massively.

Firestorm does that, too. You have to. Decompressing SL's JPEG 2000 images is really slow. You can only do 4-10 per second per CPU.

[Kathrine Jansma]

I didn't see a thread pool inside the Firestorm code (besides the KDU internal ones), but maybe I'm wrong, just did a cursory look and found the same old llQueuedThread stuff. In any case, more cores help, just not for speeding up the actual rendering due to OpenGL shortcomings.

[Ansariel Hiller]

11 hours ago, Kathrine Jansma said:

Have a look at the latest version of the Cool VL Viewer, it uses a thread pool for texture decoding, which improves rezzing speed massively.

Looking at Cool VL doesn't really help the majority of TPVs out there at all, since Cool VL is under GPL license and except Singularity all other TPVs are under LGPL, meaning they can't easily re-use that code.

Edited March 21, 2021 by Ansariel Hiller

[Henri Beauchamp]

15 hours ago, animats said:

Firestorm does that, too.

Nope !  No other viewer got it (so far); they have mono-threaded image decoding (i.e. the decoder runs in one thread, along the main program loop), but not a multi-threaded one like it is now the case for the Cool VL Viewer.

7 hours ago, Ansariel Hiller said:

Looking at Cool VL doesn't really help the majority of TPVs out there at all, since Cool VL is under GPL license and except Singularity all other TPVs are under LGPL, meaning they can't easily re-use that code.

Did I ever refuse the re-licensing of my code ?... Like I wrote recently in an email to one of FS' developers:

Quote

Yep, you can re-License as LGPL *all my viewer code*: I just kept the GPL because LL's v1 code was itself GPL (+ FLOSS), but since pretty much all today's code in my viewer got backported from LL's v2+ viewers or rewritten by me, with the exception of, perhaps, some parts of the v1 UI code from LL (that is no more in v2+ LGPL viewers, and that I did not touch), everything else can be re-licensed as LGPL. :-P

And you perfectly know this yourself (or do you want me to exhume the IM conversation logs we had in the past ?)...

As always, the condition for reusing Open Source code from another developer is giving credits to them.

As for Kathrine's multi-threaded LLImageDecodeThread code, you will have to ask her about the permission to reuse her code in your viewer.

[Ansariel Hiller]

1 hour ago, Henri Beauchamp said:

Did I ever refuse the re-licensing of my code ?... Like I wrote recently in an email to one of FS' developers:

And you perfectly know this yourself (or do you want me to exhume the IM conversation logs we had in the past ?)...

As always, the condition for reusing Open Source code from another developer is giving credits to them.

I didn't remember that to be honest. So it's good to know. Thank you! But then it was also more of a general hint that it might be easier to provide such patches directly under LGPL, since then everyone can easily make use of them. I know Liru from Singularity usually doesn't mind re-licensing things either, but ya...

What makes adding changes from Cool VL really difficult is, that you only provide a single diff for each week's change. I don't know if you commit such a change to repository as a single blob, but going through diffs that are several thousand lines long and include several different changes among lots of reformatting of code is extremely tedious and error prone. Sometimes I have a feeling you reformat code back and fourth to obscure the actual changes.

[Gabriele Graves]

It's nice and convenient to be able to copy code from other projects but developing your own using the same/similar strategy when that's not available is possible though if the feature is desirable enough, say for performance.  Unless the technique is not well known, novel and/or patented that is.

[Kathrine Jansma]

Feel free to reuse the multi threaded patch (http://sldev.free.fr/forum/viewtopic.php?f=10&t=2141#p10405)

Consider it dual-licensed under GPL and LGPL.

 

[Henri Beauchamp]

2 hours ago, Ansariel Hiller said:

I didn't remember that to be honest.

It was in 2011 and 2012, in IMs, in SL... I keep all the logs, since I won't accept anyone to doubt of my word, anytime, and I can always prove by A+B what I am asserting.

Total (and yes, sometimes quite blunt/unforgiving/harsh) honesty and reliability are among my intangible principles. I say what I do, I do what I say, always. Period.

2 hours ago, Ansariel Hiller said:

But then it was also more of a general hint that it might be easier to provide such patches directly under LGPL

What makes adding changes from Cool VL really difficult is, that you only provide a single diff for each week's change. I don't know if you commit such a change to repository as a single blob, but going through diffs that are several thousand lines long and include several different changes among lots of reformatting of code is extremely tedious and error prone. Sometimes I have a feeling you reformat code back and fourth to obscure the actual changes.

I am an old fart (and not proud of it: just a fact of life, sadly), with 40+ years of programming experience behind me. It means that I am/keep using tools that I have been using for decades ('Nedit', 'grep', 'patch', 'diff', 'find', 'cut', 'sed', bash scripts, Perl scripts, Tcl/Tk scripts...)... I know, it looks ancient (antediluvian ?), but they empower me with a productivity that many (most ?), ”modern” (”young” ?) programmers would envy.

I am sorry, but at my age, I won't ”adapt” (read: loose productivity and efficiency) to tools such as cvs, svn, hg, git (or whatever other fancy ”repository” software you can cite): I find it incredibly faster to read (yes, even with my old eyes) a ”raw” patch file (and recode it in my own way, with bug fixes and optimizations) than browsing those (or, horror: merging them and fixing merge errors), and the rhythm at which I can publish new releases (weekly, with only very sparse, part time usage of my free time), compared to the time needed by entire teams of developers to publish a release of their own viewer, should incite you to start and wonder if you are using the most efficient tools... 😜

In other words: yes, you can freely reuse my code, but no, I won't provide you with a patch (or commit) that applies cleanly to your own code... Shocking, I know ! 🤣

PS: oh, and please everyone, get it right !  The name of my viewer is ”Cool VL Viewer” (yes, ”Viewer” is part of the name !), not ”Cool VL”... Like in ”Eiffel Tower”, you know... or ”Freedom Tower”.

Edited March 21, 2021 by Henri Beauchamp

[Ansariel Hiller]

5 hours ago, Henri Beauchamp said:

I am sorry, but at my age, I won't ”adapt” (read: loose productivity and efficiency) to tools such as cvs, svn, hg, git (or whatever other fancy ”repository” software you can cite): I find it incredibly faster to read (yes, even with my old eyes) a ”raw” patch file (and recode it in my own way, with bug fixes and optimizations) than browsing those (or, horror: merging them and fixing merge errors), and the rhythm at which I can publish new releases (weekly, with only very sparse, part time usage of my free time), compared to the time needed by entire teams of developers to publish a release of their own viewer, should incite you to start and wonder if you are using the most efficient tools... 😜

It's not about the tools, but reasons like users not wanting to update each week or some other short interval. It also has to do with providing support to such a large userbase and having dozens of releases out there. And something with a rule from LL regarding a maximum of the three most recent releases out there.

Technically it wouldn't be a problem to do releases on a daily basis - the CI tool taking care of that and creating automated builds each night is doing so for quite a while already. The artefacts are just made available internally due to the aforementioned reasons.

[Ansariel Hiller]

5 hours ago, Kathrine Jansma said:

Feel free to reuse the multi threaded patch (http://sldev.free.fr/forum/viewtopic.php?f=10&t=2141#p10405)

Consider it dual-licensed under GPL and LGPL.

Thank you!

[KjartanEno]

Nice work Kathrine & Henri! I did some test comparing the latest Cool VL Viewer to a version from last August. I see around 15% improvement in framerates on my system. I used CoreCtrl, a Linux tool for managing CPU and GPU settings. It's especially needed for AMD graphics cards since we lack even the most basic GUI GPU control panel on Linux. I'm still a bit concerned that Cool VL Viewer, when configured the same(*) way as other viewers, appears to not be fully utilizing the GPU at all times as seen by the dips in the bright green line on the CoreCtrl panel. Viewers were allowed to 'rest' for a few minutes before each screenshot and no other major programs were consuming system resources at the time the image was taken.

Links to video captured using SimpleScreenRecorder of a trip through part of Bellisseria using Firestorm and Cool VL Viewer:

https://www.dropbox.com/s/22v6dgas25fsvwg/CVLV-1.28.2.15-boating.mp4?dl=0

https://www.dropbox.com/s/e6celnppig9fm8z/FS-6.4.13-boating.mp4?dl=0

* The Same Way: Using settings that appear to be the same across all viewers which will provide an equivalent experience visually.

Edited March 21, 2021 by KjartanEno
formatting

[KjartanEno]

I might as well add Kokua and Alchemy too...

Alchemy with EEP is still in beta.

[KjartanEno]

I needed to know if the Cool VL Viewer issue mentioned in my previous post was due to my main computer having an AMD Ryzen CPU and AMD graphics running MESA open source drivers. I have another computer with an Intel i3 and Nvidia GTX 960 graphics card that I rarely use for SL, so I installed the latest versions of Firestorm and Cool VL Viewer on it. It uses Nvidia proprietary graphics drivers. My GPU monitoring tool in this case is NVTOP. Cool VL Viewer is not keeping the GPU at 100% while Firestorm is. Background yield time is set to 0 on both viewers, so there is no difference whether NVTOP or the viewer is in active focus by the desktop environment.