Enable Multi Threading On Firestorm

[Tristan Greymoon]

Title says it all, I want to know how to enable, multi threading on the Firestorm Viewer. I can't find the option any where :(

[Ceera Murakami]

Preterences > Advanced > Allow Multiple Viewers

That will allow multiple instances of SL to run on the same computer, with Firestorm.

If by "Multi-threading" you mean the ability to properly spread the processing workload across multiple CPU's on a multi-core computer, that function has never worked in SL, with any Viewer that I am aware of.

[Vladi Hazelnut]

Its not an option on the V2 viewers that I am aware of. I think its automatically on. I looked for it in the debug menu on both LL's v2 and firestorm and there is no option for it. But it does indeed run multi threaded when I check my cpu usage.

And the option does work in sl, even on phoenix. It just doesn't spread them out evenly is all.

[Ceera Murakami]

Well, what I mean by "it doesn't work" is that proper multithreading would assign one instance of SL to one core, a second instance to a different core, and maybe my web browser to a third one. Or it would spread the load evenly across all cores.

SL doesn't do that. With V1, it only saw one core, period. With V2, including Firestorm, it spams all the cores available, but the window that has focus gets the vast majority of the CPU cycles, and a much higher frame rate than any other concurrently running SL instances..

If it worked right, two instances of SL running on a 2 to 4 core computer would each get the same frame rate. But on most computers, the bottleneck isn't CPU power - it's graphics card power. And most computers only have one graphics card in use. A really well-done multi-threaded application would be able to overcome that.

[leliel Mirihi]

---

Ceera Murakami wrote:

Well, what I mean by "it doesn't work" is that proper multithreading would assign one instance of SL to one core, a second instance to a different core, and maybe my web browser to a third one. Or it would spread the load evenly across all cores.

SL doesn't do that. With V1, it only saw one core, period. With V2, including Firestorm, it spams all the cores available, but the window that has focus gets the vast majority of the CPU cycles, and a much higher frame rate than any other concurrently running SL instances..

If it worked right, two instances of SL running on a 2 to 4 core computer would each get the same frame rate. But on most computers, the bottleneck isn't CPU power - it's graphics card power. And most computers only have one graphics card in use. A really well-done multi-threaded application would be able to overcome that.

---

The viewer intentionally caps the frame rate when the window is not in focus. You can control it with the debug setting BackgroundYieldTime, setting it to 0 will cause the viewer to always run at full speed.

[Ceera Murakami]

---

leliel Mirihi wrote:

The viewer intentionally caps the frame rate when the window is not in focus. You can control it with the debug setting BackgroundYieldTime, setting it to 0 will cause the viewer to always run at full speed.

---

Tried that, and ugh! Was at about 30 FPS with one window open. Second window got 3 FPS, while the one that had no focus jumped to 40+? Had to change it back to defaults. That was just too unstable.

[leliel Mirihi]

---

Ceera Murakami wrote:

Tried that, and ugh! Was at about 30 FPS with one window open. Second window got 3 FPS, while the one that had no focus jumped to 40+? Had to change it back to defaults. That was just too unstable.

---

 

I think that's to be expected when trying to run multiple viewers at full speed. You'll probably have to play around with BackgroundYieldTime and TextureMemory. Settings that give a good balance will be highly dependent on your system and the workload of each viewer.

[Incoherendt Randt]

---

Tristan Greymoon wrote:

Title says it all, I want to know how to enable, multi threading on the Firestorm Viewer. I can't find the option any where

---

Heya, the old run multiple threads thing from Advanced-Rendering is on all the time now, but it still doesn't really do a heck of a lot. Most of the code never tries to use them.

[Vladi Hazelnut]

It does work however, I tested it on a viewer that you can disable it. I get higher frame rates with multi threading on than with it off. The down side I noticed is that it always pegs out one of my cores, even if I have sl minimized. With multi threading off and a high back ground yeild time my proccessor use goes almost to zero for all cores with sl minimized.

As for the background yeild time I have mine set at 400 because I don't want sl eating up power when I have it minimized or in the background. I often run several other programs besides sl like blender, firefox and other texture software. I would rather have the power diverted to the program I am actively using so it renders faster.

And as for running mulitple viewers, windows is going to naturally assign more processing power to the one in active use, its the way it is designed. You can adjust it though, I am just not  sure to what extent, never messed with it myself. I would think the best way to run more than one viewer at a time would be to run it on multiple monitors and even better yet with dual video cards on multiple monitors.

also increasing the background yeild time will help with running multiple viewers. The only problem is the that the currently active window will get more resources and the one in the background will run choppy. To run them both at the same rate would take a pretty kick ass computer, and like I said I am not even sure windows will spread the power evenly between the two even if you wanted it to. At least running them both on the same monitor.

[Sparks Racecourse]

Actually, it be in the debug settings.  I see it on the other viewers, but not Firestorm.    (RunMultipleThreads),  It is on Kirstens Viewer and Phoenix viewer, but it seems it has been left off Firestorm.   I found Beta 2 of Firestorm to be quite buggy, so I tried Kirstens Viewer S21 (9).  It is rather nice and it can acutally see a mesh object, unlike the current Firestorm.   So, try that viewer until the Phoenix team releases the next beta 3 or their 3.01 version.

[Koozebane Koolhoven]

I'm actually having problems with multi threading on any viewer.

 

Second Live insists on running on core 4 no matter what I try.

 

Has anyone else noticed this?

[Helium Loon]

---

Ceera Murakami wrote:

Well, what I mean by "it doesn't work" is that proper multithreading would assign one instance of SL to one core, a second instance to a different core, and maybe my web browser to a third one. Or it would spread the load evenly across all cores.

SL doesn't do that. With V1, it only saw one core, period. With V2, including Firestorm, it spams all the cores available, but the window that has focus gets the vast majority of the CPU cycles, and a much higher frame rate than any other concurrently running SL instances..

If it worked right, two instances of SL running on a 2 to 4 core computer would each get the same frame rate. But on most computers, the bottleneck isn't CPU power - it's graphics card power. And most computers only have one graphics card in use. A really well-done multi-threaded application would be able to overcome that.

---

I think some people here don't fully grasp what 'multi-threaded' really means.

 

The example about one instance being assigned to one core, and such.....that isn't a threading issue.  It's a processor affinity setting.  Start your instance of SL, bring up the task manager, right-click on the SL process, and select the processor affinity.  Repeat as needed.  You'll need to run it single-threaded for this to hold up, though.

Threads are started by processes.  A process is what you are calling an 'instance' of in this case (though in actuality, there are several processes started when SL starts up....like the SL plugin host.)  Threads are simplified execution sets that run timesliced on a given core (though they can run on other cores than the initiating process.)

In order to avoid hideous lag within a given thread, the task the thread works on needs to be as independant as possible from the other threads of that process (so it can continue to do what it does without waiting on the other threads.)

In a highly graphically oriented application like SL, multi-threading will keep things from 'freezing' and improve performance in many areas.  But by the nature of what each thread does, and how often or how fast it accomplishes it, as well as the thread's priority, it will NOT take the same amount of CPU time as other threads.  Balancing threads is not usually a concern.....unless the application is likely to peg ALL or most of the cores available, then it becomes an issue.  Typically, in an application like SL (or a 3D game) the majority of the CPU is consumed by the rendering thread.....mostly due to handling the setup, changes, and other things that feed the GPU.  Another thread may be handling Network communications, another handling sound, another synchronizing things, etc.  Those are not nearly as time-critical as the rendering thread.

ALL threads yield time and allow other threads in the same core to execute.  This means that no thread can starve all the others.  But one or two threads can still dominate the CPU usage on a given core.  This is expected.  And since 3D rendering usually happens as fast as possible (i.e., no frame-rate target caps.....just get as much as possible) the core that the rendering thread runs in will typically peg (sometimes only to 50%, if hyperthreading is involved).

While it would be nice to have dynamic multi-processing auto-balanced across cores in a CPU, applications and operating systems can't yet, and the overhead in hardware in the CPU itself would be excessive.  Hardware and the OS depend on the software to distribute things as evenly as it can across threads, but that is limited by the nature of the application.....not all apps balance well.

MIMD parallelism is tough to work with.  Take it from someone who's written code for SIMD, MISD, and MIMD parallel processor machines.  Threading makes it simpler to program, and efficient enough as long as the threads are created with proper priorities by the host process.

 

Now as to getting the same framerate on two simultaneous SL processes running on a single CPU.....No, not the way it works.  Several issues with that.  First is bus contention (that PCI-E bus can only have one master at a time.)  So even if one process has finished with it, the next may not get it immediately.  There is also overhead with task switching, and unless the processes are viewing the exact same scene at the same resolution and settings, it is NOT going to be the same.  There is also contention in resources (network usage, for example) that will cause additional delays.  Let's not even talk about cache and disk access issues.  But, even assuming two GPUs, two network cards, separate hard drives and separate controllers, separate monitors......the OS is still doing other things in the background, and some of it may be executing on some of those cores.  Which can cause additional imbalances in load and other contentions with resources.

 

As for the bottleneck being GPU power, that's not really the issue.  The issue is the way the GPU pipeline works, and what has to be done to prepare a scene.  If a single GPU is being used, then each process has to get access to it, and ALL the currently cached rendering setup is invalidated, and has to be redone from scratch.  Some textures may remain cached, but there are no guarantees.  The transforms, shaders, camera properties....everything about how it renders a frame....has to be re-configured for the next process.  And this happens pretty much every frame or two (as the PCI-E bus yeilds control from one SL process to the other.)  In other words, a significant slowdown just trying to run two simultaneous SL processes.

 

No amount of programming skill or technique really overcomes the limitations inherent in the hardware designs.  We can try to minimize the impact, but in the end, we software engineers are limited in just how much we can do in that regard.

 

[Fiona Classito]

I was wondering the same thing myself. Did you ever get an answer?

I have a Quad-core processor (AMD Phenom 9550), and in Windows Task Manager, one of the cores is constantly pegged when I am running Firestorm. It never falls below 95-100%

When I use the SL Viewer2, however, the total CPU usage is about the same but it appears to be spread across all four cores - none of them are anywhere near 100%.

I read that it is not particularly healthy to allow one of the cores to run at 100% continuously. Does anyone know if this is true?

[Fiona Classito]

@Koozebane - I just wanted to share that mine was doing the same - core 4 was running at or near 100% constantly as long as SL (in this case the Firestorm viewer) was running. I found out that turning OFF "Threaded Optimization" in my nVidia video card settings solved this problem. Vladi seemed to describe something similar. I haven't notice much of a change in my fps either way, but I feel better that one of my cores isn't constantly pegged now.

Let me know if you need more info and I can direct you to the wiki.