Multithreading

hello,

maybe i am wrong, but as far as i understand TD can make use of only CPU core at a time.
It could be great to leverage the power of TD by making use of user defined number of cores like in After Effects when rendering scenes

thanks a lot

I’m not sure if that’s how it works exactly, but the common practice is to try to put more on your gpu then your cpu whenever possible. There’s a bit in the wiki about resource management. There’s also ways of simulating multi-threading using python in touchDesigner but it will never be true multi threading. From my knowledge Python is not capable of true multi-threading and since TD is python based you may not beable to. Although they are both similar to some degree, TD renders thing dynamically to be played in real time. After Effects aims at rendering a composition into a video file and is built from c++, which has the ability to multi-thread but not be dynamic like TD. Comparing the two render pipelines is like comparing apples and oranges unfortunately.

thanks for the heads up !

i am not a coder so i don’t really know the underlying technical details. Python is a scripting language, but TD is C++ at its core. Image treatment is done at the C++ level right ? TOPs are CPU based so it would help using CPU cores.
If Python is the limitation, well so be it !

I find it lame that we have ultra powerful multicore CPUs and we (generally speaking) barely use more than one core a a time

Gallo is correct, Python is only the scripting language, the majority of the real processing happens at the C++ level so is quite fast.

[url]http://www.derivative.ca/wiki099/index.php?title=FAQ[/url]

You’ll find a little answer about multi-threading in the faq linked above. Essentially movie decoding is a huge advantage for multi-threading purposes among a few other nice benefits.

To utilize a truly separate thread/processor on a multi-core system you can in fact just start another instance of TD. This is very common practice on complex systems made in TD for large installations, things that need heavy CPU processing of input data, circumstances where you can’t allow the processing on the CPU to hiccup the rendering and/or when you need something to process at a faster than screen refresh rate ( eg, analyzing incoming gesture data at 120 hz and applying a subtle amount of smoothing before handing off to a 60hz rendering thread).

It is definitely an “advanced” use case, but there are many operators made to handle this workflow including all of the Touch In/Out OPs, and the Shared Memory OPs. There are talks of one day hiding these into an internal multi-threading feature, but for now if you need to utilize another core for something specialized beyond movie decoding it is totally possible!

But when it comes to actually rendering imagery, you will find that unless you have an incredibly specific and customized setup you can’t easily use CPU multi-threading for this purpose in TD ( though it is technically possible!). But the power, as Dodafilm mentioned, for TD rendering is in its use of the GPU in a similar way to a game engine for realtime rendering primarily.

Thanks for the information.

So why TD wouldn’t be multi-threaded by design ? or at least instead of launching another instance of TD, TOPs or whatever processing compatible/useful operator could be multi-treaded or have an option to chose a core or a number of cores available for a specific processing.

Gallo - my understanding is that multithreading is generally messy for openGL as any calls will go through the driver where function calls are collected into command lists before being handed over to the GPU - which may or may not result in a performance boost. On windows machines you can bind a GPU to a touch process with GPU affinity (only on quadro cards), which does have significant performance benefits in some cases.

How GPU API calls will certainly change, especially with Vlukan; but historically I think the challenge of consistent behavior and high performance has meant that touch has been largely single threaded (with some exceptions) for the sanity of the devs working in this environment - removing the necessity of thread or process management that would likely accompany that kind of division of labor cpu side.

That said, Derivative is generally very receptive to ideas for improvement especially if you have a clear idea of what the implementation would look like.

Thanks Raganmd.

I don’t really have precise idea on how to achieve that (if achievable anyway). As i said, i just noticed, as a user, that lots of software packages make use of only one CPU core. So i was just wondering.

Anyway, if most of software don’t make use of all cores, maybe there is a good reason :wink:

Nope, TOPs are entirely on the GPU (except for ones that pull information down from GPU to CPU, which is a slow process!).

SOPs and CHOPs are CPU based.

Ok my bad ! i understand CHOPs are CPU based operators but i thought anything dealing with geometry was GPU based and video, images and compositing processing was CPU based ! A bit confusing.

As a general note, the main process of deciding what to do every frame (the network OPs) needs to happen in one thread, as everything is dependent on the other tasks. In essence, multi-threading is best for parallel tasks, and Touch does pretty well in that it decodes movies in multiple threads, and it does all the GPU work in a different thread (for free, that’s just the way you program a GPU).

In terms of comparing to AE - yes, TouchDesigner is multi-threaded, but more to the point, it uses the GPU heavily, which is where AE is trying to get to.

Bruce