PDA

View Full Version : Lightwave firing on all cilinders?



Brötje
11-29-2012, 07:03 AM
Hi everyone,

Just something I came across when fiddling around in Houdini Apprentice edition. It seems Houdini uses all processors, all the time. Importing, exporting, baking,.... When I look at LW ( for example, importing FBX, or fracturing geometry,... ) I see only one core franticly trying to calculate everything, while the other cores ( 23 in my case... ) do absolutely nothing. Since LW is now 64Bit, will it ever use all cores for things other than rendering?

Just wondering.

Boris Goreta
11-29-2012, 07:17 AM
I don't think 64 bits have anything to do with multithreading. Lightwave has Threaded Mesh Eval checkbox in Preferences so in some situations it uses more than 1 core, never at 100% though and you're right, mostly it is just 1 core.

metahumanity
11-29-2012, 07:52 AM
That´s a pity. If LW used all Cores many speed OpenGL problems wouldn´t even a problem a all.

dsol
11-29-2012, 08:01 AM
Yep, as others say - it depends on what you're doing at the time. Rendering certainly hammers every core you have. And I think multi-threaded OpenGL was added at some point in the 9.x cycle (though can't remember if it was kept).

Getting the app more deeply multithreaded in any areas that need speed is always a good thing, though certain operations are very difficult or impossible to make parallel.

dsol
12-03-2012, 07:59 AM
Actually, after struggling with a very dense scene and looking at my CPU usage while the app freezes up waiting to finish calculating instances and deformations (with only a single core in use!), I think I can safely say Lightwave really REALLY needs deeper use of multithreading.

jwiede
12-03-2012, 10:48 AM
Actually, after struggling with a very dense scene and looking at my CPU usage while the app freezes up waiting to finish calculating instances and deformations (with only a single core in use!), I think I can safely say Lightwave really REALLY needs deeper use of multithreading.
Obviously not all tasks can be efficiently broken into multiple threads, but other pkgs seem to make a LOT better use of available cores, esp. in modeling/tool ops and viewport handling. I really hope the new tools coming in 11.5 are equipped to take much better advantage of multithreading.

Slight inefficiencies on small geometry working sets would be fine IMO if it means that the tools can efficiently decompose and multithread algorithms when handed large working sets. Small working sets are typically IO/UX-bound anyway, so the cost of determining whether workload size merits decomposition effectively disappear in practice. Put another way, if operations _can_ be multithreaded, then they're worth multithreading (even if the gain seems minimal for small working sets), given modern working set sizes.

dsol
12-03-2012, 11:28 AM
Yep - for simple scenes, you don't notice the sluggishness so much. But as soon as you go to a few thousand instances applied to a deformed surface mesh, the whole thing gets achingly slow. Even worse, hiding the objects - even turning them "off" in the scene editor - makes no difference to the speed of interaction. It really exposes the creaky underpinnings of some of the LW codebase.

I generally like the Lightwave interface - and I really like the renderer. I just hope they can excise a lot of the aging (procedural non-threaded C-based) code in LW12. Otherwise I really will need to look at alternatives for future projects. I blame it on ZBrush - it's spoiled me by handling millions of polys so effortlessly!

dsol
12-03-2012, 11:44 AM
Having a non-locking multithreaded UI would help the perception of speed a lot. That's a big rewrite though.

stevecullum
12-03-2012, 12:34 PM
If I understand things correctly, to multi-thread a something, it has to execute independently of any other system. So for Houdini where everything in the program is as an independent node, multi-threading becomes a viable solution. But with LW and probably a lot of other software, where there a many dependencies with other parts of the architecture, this becomes impossible for many tasks.

Having said all that, I'm not hardcore coder, so I may have some of my interpretation of the multi-thread requirements wrong.

jeric_synergy
12-03-2012, 01:32 PM
Certainly we'd hope for that in 12, but I wouldn't count on it for 11.5, it's gotta be a big job.

With any luck ("WAL" henceforth) multi-threading will become part of the compilation process AFAP.

dsol
12-03-2012, 06:40 PM
If I understand things correctly, to multi-thread a something, it has to execute independently of any other system. So for Houdini where everything in the program is as an independent node, multi-threading becomes a viable solution. But with LW and probably a lot of other software, where there a many dependencies with other parts of the architecture, this becomes impossible for many tasks.

Having said all that, I'm not hardcore coder, so I may have some of my interpretation of the multi-thread requirements wrong.

That's pretty accurate as I understand it. IIRC There's a section of the Houdini SDK devoted specifically to multithreading - and how to use built in APIs to support it nicely. Hopefully (I say that word a lot!) we'll see LW move to the Core Nodal Scene Graph model internally in 12 - or some time in the not-too-far future. That might help, right?

stevecullum
12-04-2012, 06:14 AM
Hopefully (I say that word a lot!) we'll see LW move to the Core Nodal Scene Graph model internally in 12 - or some time in the not-too-far future. That might help, right?

In theory - yes, but likely you would only see parts of an entire process be multi-threaded. Take for instance deforming a mesh. You could write a new deformer that is multi-threaded, but you would also need to multi-thread the code the defines the mesh in the first place. If you strip everything away from LW, you would be left with the core code that defines the points in space that goes onto make up the polys which makes the objects, etc.. I'm guessing that's the legacy code, that is part of every system in LW. To make LW faster all round, you need to speed up that part of the code probably.

Perhaps someone with actual LW coding experience could chime in here! :)

dsol
12-04-2012, 07:42 AM
I dunno... When I go to render - if LW's render status text is correct - it calculates object deformations/transforms sequentially, rather than in parallel. If they could just break the dependency locking here so each object in the scene is evaluated on its own thread - or ideally queued in a list using blocks (to reduce kernal thrashing) - then we'd immediately see a huge speed up in most large scenes. Most scenes have surprisingly little dependency between objects when calculating deformations/transformations. It's only when you're using physics that it gets tricky to parallel-ise.

Another big potential speedup feature - cacheing objects that don't change state between frames instead of recalculating each time. I think it does this sometimes already (with simple setups). Once the internal scene format moves to a more nodal design, it might be possible to cache at a more granular level. Some scenes, I'd gladly trade off a few gigabytes of RAM for caching, if it shaved 10% off my render time. These days, RAM is (relatively) cheap, but high-end CPUs are not!