Dual processor support, and Mac client

Does the SL client support multi-threading across dual processors?

It seems that what with the intensive activity of streaming, rendering, interface usage and general what-have-you going on, that this would be a Good Thing.

Awaiting delivery of a dual processor G5 , so I would be really interested to know...

SL is exhibiting almost continual packet loss just lately for me (whenever I try and move anyway) on my older single processor G4 Mac and I wonder if this is in part due to the machine being just too busy struggling with everything else. The machine is otherwise quite speedy for any game or application but SL which just lately is like wading through treacle to move, chat, or indeed get anything done in-world.

Also, any news on speed optimisation and release from Beta of the Mac Client ?

Not right now. On Windows, SecondLife has one main thread that does the UI handling, network response and rendering, and a few minor threads that combined get maybe 1% of the processor time. I think the Mac is the same.

Thanks Carnildo

Shame to hear that but perhaps it's something for the 'desirable features list'...

I guess the huge and continual packet loss I get when moving around lately is probably not unrelated to the machine struggling to render if it's all on one thread ? I definitely get problems with changing clothes and attachments too.

This machine only has a Radeon 8500 on AGP 2X, and the 1.25Ghz G4 CPU only has a 100Mhz bus feeding it so I would imagine there's a fair amount of saturation going on all over. The interface is virtually unusable sometimes, have to wait a few seconds for response to a key press !

Will be interesting to see what difference the new DP machine makes, apart from it being faster in any case, at least SL won't necessarily have to share one CPU with all the other OS activity so there should be some benefit there, I hope

Considering the advent of hyper-threading technology, that seems extremely short-sighted to me. Even people without dual processors can benefit greatly from hyper-threading in a multi-threaded application.

well in openGL the gui is part of the rendering, theres no simple way to change that... since they both share the same display context. (aka the gui is drawn within openGL itself, not as a seperate gdi overlay over the openGL 3d space)

the networking could i imagine be shunted to a seperate thread (possibly even now) but im not sure how much that would accomplish.

The basic problem is thats just a very slow machine to be using with SL. The bus is terrible, the cpu is by modern considerations (and sl's basic needs) fairly antiquated.. and that graphics card is now three generations old

You were absolutely right eltee ! On a new machine, nearly all of my 'lag' has gone away, no more wading through treacle

However, I can clearly see that one processor is getting hammered by the SL main process thread, with plenty of spare capacity on the other, so whether for dual processors or hyper threading, it would be nice to see whether some improved multi threading could be implemented.

I suspect it'd accomplish more than a lot of people think. Since 1.5, there's been a bug where client FPS and ping time drop and soar respectively, apparently "feeding off" each other, as each parts of the single thread is neglected in favour of another. This can cause extreme rendering AND networking lag for between 30 to 60 seconds. The best we could come up with as to a repeatable cause was that it happens when an agent moves into a sim, and the new user's client hasn't cached any of the objects. Worse still, something in the server code seems to make it happen for everyone in the sim, regardless of their proximity to the new avatar.

Now, obviously this isn't strictly a call for dual-threading, since I'm certain this hasn't always been the case. However, were SL's rendering and networking components on seperate threads, we wouldn't see this happening nearly as much, and in theory, those of you with multiple CPUs could see SL's rendering thread as the only activity on one CPU, with all other functions being handled on another.

Of course, better still would be if there was some sort of optimized 3D coprocessor that handled the rendering, rather than the slower, general-purpose CPU. You know, like a GPU.

The effect of decoupling the networking and rendering code into separate threads could be quite vast, because of the intensive and extensive server-client dialogue that occurs almost continually when in the presence of scripted objects. (They dirty their own prim and then that contaminates the entire link set which then invalidates all the respective client cache entries, and then the dialogue is required to revalidate them before the client is allowed to pull the corresponding data out of its cache. Plus, more downloads, ouch.)

There's so much of this going on all the time in typical well urbanized areas that slowing down the networking by keeping it on the rendering thread is creating something like an O(n^2) problem, or maybe worse, not only because there is more rendering and more dialogue, but because the longer that the dialogue takes, the more additional dialogue is required, since scripts continue ticking along at a steady rate.

Hyperthreading will help a bit if rendering/networking are decoupled since most code creates stalled CPU pipelines, and these two largely independent tasks can use the CPU resources that this vacates quite nicely. That's useful, but there's another benefit of decoupling: we'll get a significant gain from the overlapping of I/O wait and CPU-based rendering, because the renderer will not need to enter a network poll loop at all and the networking will never have to wait for rendering to complete at all. Client responsiveness should be much greater as a result, and combine that with the effect of HT and it's a big win.

And of course, dual processor machines are very common now, so with HT on each ... There's bound to be enough work for 4 threads.

Yes please, LL, decouple the internals and support HT plus dual CPUs. SL is pretty demanding of resources --- not using the resources available on our machines makes no sense. And the GPU, like Cath says!

Hey! I want to be able to use all of my G5 by SL! Hopefully dual processor support will be added in a few releases. 1.9 anyone?

actually on the server side its essentially meaningless (aka you can do whatever you want with yer client, it won't really affect server performance (tho obviosuly client changes would affect multiple clients in a region with a poorly scripted object))

i think a big barrier to it though would be localization to multiple platforms... in that each platform has generally wholly different completely incompatable thread functions.

at the same time openGL limitations will probably make rendering the gui on a completely different thread from the rest of the render speace (hopefully making that more responsive even in low frame rate areas) essentially meaningless as the whole thing needs to be done in one final draw pass to the back buffer.

also don't forget that with multiple threading there are other limitations when attempting to run on a single processor system (which make up >99% of current SL systems easily) where now you have two threads competing for the single processing resource and its up to the scheduler outside of the game to determine what gets what cpu allocation, and that can be a rather undesirable situation.

Two threads will never compete in the way that suggests except when both are CPU-limited and the operating system has to timeslice them.

That would not occur in the case of separate networking and rendering threads, because rendering can only render those objects that have valid cache entries (and that requires network access to determine), and networking involves external I/O which the operating system always uses as task switch points the instant that there is any network wait.

Actually, I have found out a few things anout that machine in question. While yes, it should multi without a problem, there are a few basic limitations. One of the main ones being the fact that at this time, there is no way to "break up" the graphics and primary program to run them seperately, which as you may have guessed, would speed things up. *goes back to paying attention to the trainer in her Tier 1 tech support class for Apple*

There is always a way.

The general most rapid approach to refactoring a combined network/render mainloop is to replace each network input polling point within the rendering loop by a network event polling point, replace each network output call by a injection into the outbound network queue, then make the new networking thread mainloop accept those queued tasks from rendering, and finally make the networking generate new events for the rendering to process when network input is received.

That gives you the basic thread decoupling, although it's not the end of the job but just the first cut, and there may be gotches in the way if the networking code is currently a mess and not self-contained. It also presupposes that there is a decent event mechanism in place in the client, although that is very likely in modern code.

To be blunt and to the point...exactly.