Jump to content

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


DNArt
 Share

You are about to reply to a thread that has been inactive for 176 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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.   

  • Like 5
Link to comment
Share on other sites

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!).

 

  • Like 2
Link to comment
Share on other sites

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 by panterapolnocy
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 by Ardy Lay
  • Like 1
  • Haha 1
Link to comment
Share on other sites

  • 3 weeks later...

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.

 

Link to comment
Share on other sites

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 by Mollymews
nois
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Ansariel Hiller
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. ;)

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Henri Beauchamp
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

CVLV-1_28.0_6AVX.thumb.jpg.2076a2cc6cb4939564956a244954b30d.jpg

CVLV-1_28.2_15.thumb.jpg.a6cac073f52b4de83ed55a895cc72fdc.jpg

Firestorm-6.4_13.63251.thumb.jpg.4fbf04c12257c6b8adae1dab6db4ba4f.jpg

Singularity-1.8.9_8419.thumb.jpg.36cdef0a77397daaa4e7ec52dbad2401.jpg

Edited by KjartanEno
formatting
Link to comment
Share on other sites

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. 

CVLV-1_28.2.15-Intel-Nvidia.thumb.jpg.ce482709e1631c32c74b7244bd8cce1b.jpg

Firestorm-6.4_13.63251-Intel-Nvidia.thumb.jpg.bb8d53ec55b0ca0a82ea3d4c7b6e6f25.jpg

Link to comment
Share on other sites

@KjartanEno

Again ?...

For a start, you are diverting this thread from its original topic which is not about the GPU load, but about multi-threading. The improvement brought to the latest Cool VL Viewer version won't change a thing to how high is the GPU load (or to the frame rates) in static scenes, but how fast textures are rezzing on login, after a far TP, or while moving around (the latter even more obviously when the new ”Boost textures fetches with speed” feature is enabled, in Advanced -> Rendering -> Textures).

Second, look at the About boxes, and see how the CPU frequency jumps up and down for the same viewer or between viewers. Obviously, there is something amiss with your system(s) since as soon as any viewer is logged in and rendering any scene, the CPU freq should go to turbo for the core running the main thread and not budge from it !

Simply LOCK your CPU to its maximum frequency on all its cores to achieve the maximum performances.

One thing is certain: on my various systems, the GPU load is constant (but so is my CPU frequency) and yet well below 100% (more like around 40-70% for a GTX1070Ti, depending on the scene being rendered), even with ALM+shadows+everything on: with anything equal or better to a GTX960, the SL viewers are 100% CPU-limited; it also means that if the frequency of the CPU core running the render pipeline (i.e. the main viewer thread) goes up and down, the GPU load will follow it.

Edited by Henri Beauchamp
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 176 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...