|
|
Render speed and memory use
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
Render speed and memory use // Archive: Tech Forum
Post by Changa // Jul 25, 2007, 12:47am
|
Changa
Total Posts: 187
|
Hi, I have a technical question to experts and food for experiments to the Ts community.
1. Can we use few TS tasks concarrently running on one multiprosessor PC to expidate rendering? As I figure out from the previous discussions multithreading does not increase speed twice. What if use two Ts with multithreading off? I think it is possible for rendering of the different frames of animation for instance. I'm not sure about power of using of TsNet in one machine for this purpose, but may be it's even possible for split rendering of one frame.
2. Another question following the first one. If Ts in it receint 32b state can manage up to 2G of memory only, probably 64b operation system can manage few TSs with 2G limit each in bigger memory field? |
Post by parva // Jul 25, 2007, 1:00am
|
parva
Total Posts: 822
|
Not really sure what you want to ask.
Multithreading depends on the threads the program distribute to the cpu means if you have a dual core machine, 2 threads will be running, quad = 4, and so on, so indeed multithreading will double the speed (maybe not definitivly at 2 threads but thats another story).
Opening 2 truespace tasks will not render any faster I guess, but of course have to admit I haven't tested it yet, I just doubt that.
It would just split the priority and give 50-50 of the cpu power/usage to the individual programs. |
Post by Changa // Jul 25, 2007, 1:45am
|
Changa
Total Posts: 187
|
Ts spends part of the time in preparation for rendering - reading textures etc with low CPU usage (<25 % of single processor). Sometimes it takes about half of the rendering time. Why not to use this time and the unused power for another rendering process?
Be honest, my second question seems to me more interesting. |
Post by chrisj // Jul 25, 2007, 2:23am
|
chrisj
Total Posts: 239
|
I noticed that vray renders in multithread, but the lightmap calculations are only a single thread. Just thought I'd mention it. |
Post by Bobbins // Jul 25, 2007, 3:14am
|
Bobbins
Total Posts: 506
|
Some code is inherently single threaded, such as shadow map generation in LightWorks will only ever single thread even if the renderer is set to multithread. There are a lot of 3rd party shaders for LightWorks (in fact most of them) which are single threaded code, so whenever LightWorks hits one of those shaders multi-threading ceases. VRay is similar, while VirtuaLight is only ever single threaded.
Running two instances of tS in single thread mode will be a lot slower than running a single instance multithreaded for renders as the Windows scheduler has a lot more overhead to transfer execution between the two applications than to stay multithreading the same application. Windows is also doing a lot of other functions as well as running tS - you'll have print spooler services, anti-virus software intruding into every disk and network I/O, networking services, maybe e-mail running, web browser software, instant messaging and so on. With all those things to do, adding another instance of tS to the mix won't help. |
Post by frootee // Jul 25, 2007, 3:39am
|
frootee
Total Posts: 2667
|
Sipmly stated, multithreading processes spawn more than one thread per CPU. Even on a single CPU multithreading is possible.
As Bobbins pointed out, other processes are also running, taking up CPU time: each takes its own amount of CPU time. You may be able to get more CPU time for truespace if you kill the unnecessary processes (audio, printer, etc.). If you wanted to go all out, have a single barebones render machine, with only truespace and antivirus software, as well as other operations-essential applications on it.
tsnet is a great application for multiple computer systems. You can render a single still image across multiple computers. Each computer gets a portion of the image to render, then the spawning system assembles the two parts into a single image.
Lars Nilsson (quantumchamaeleon) may be able to better explain the use of tsnet on a single system; since he is the developer.
Froo |
Post by Changa // Jul 25, 2007, 12:00pm
|
Changa
Total Posts: 187
|
I spend this evening experimenting and the results show that my initial question was not so stupid. The test was done on the same still scene with 600x400 screen rendering. The winner is triple TS (multithreading off) with 2 min 40 sec per frame result that 16 sec or 9% faster than one TS with multithreading. During the TSx3 and TSx4 rendering memory usage peak steps over 3GB. That means that large size rendering can be done using TsNet and few TS instances even in one system. Of course if it is possible. Question to Lars Nilsson;) |
Post by frootee // Jul 25, 2007, 12:20pm
|
frootee
Total Posts: 2667
|
Cool. I never tried using tsnet on a single system. Interesting results!
Froo |
Post by chamaeleon // Jul 26, 2007, 10:32am
|
chamaeleon
Total Posts: 74
|
Right away, I'd just like to say that tSNet will not use more than one instance of trueSpace on a single machine. Not because it's impossible, it's just something I didn't really anticipate people would do, and certain details in the implementation reflect this.
Regarding the performance comparison between multiple instances of trueSpace vs multi-thread rendering, I can only venture a guess (perhaps not even an educated one). I'm guessing that, due to the fact that separate processes does not share memory, while threads do, the multiple process instances might perform better as the running code doesn't compete for access to the same resources (memory containing scene data), etc, but can access anything without competing with other threads, some time is saved (I have no inside knowledge regarding how problematic multi-threaded access to scene data is during rendering of course, I may be way off target). The drawback of using multiple instances of trueSpace is of course that you're paying dearly in memory usage.
Finally, I would really stress the need for more testing of the various configurations before drawing too many conclusions. More or less scene geometry complexity, more or less textures and different shaders, etc, scenes that takes much longer to render. This is of course a pretty obvious point.
My $0.02 for whatever it's worth. :) |
Post by Changa // Jul 26, 2007, 9:27pm
|
Changa
Total Posts: 187
|
Thanks everebody for your posts. Thanks Lars.
I agree it needs more testing. Can tell you that I came to the idea of joining few Ts instances because I faced the problem of lack of memory for large rendering. My system has 4G of RAM, but practically it's almost impossible to render more than 3000x2000 image even with AA. I don't say about 3A or 4A. My experiments with bigger sizes usually faild with "Vray rendering command faild" message at the start point. I believe that now, then Caligari has serious thoughts about 64bits future of TS, which is convenient not for all Ts users at the moment, one of the solutions would be an application that can join few TS instances running in a single system into one rendering job.
Your opinions? |
Post by chamaeleon // Jul 27, 2007, 3:56am
|
chamaeleon
Total Posts: 74
|
Well, I've rendered a 16k x 16k picture using Lightworks by splitting it up into pieces that are less than or equal to the max 8k x 8k that Lightworks support and stitching it back to together (automatically of course, using tSNet ;), I think I rendered 16 4k x 4x pieces), while V-Ray does not like this at all, and rendering of individual pieces fail as soon as the total image size is on the order of 3k x 2k, just like everyone else is seeing.
I have no insight as to why V-Ray would suffer from this while Lightworks does not. Perhaps it's inherent in V-Ray as a renderer, perhaps it's a lack of flexibility in the rendering API that Caligari uses. Either way, V-Ray does seem to let anyone go above those numbers to any great extent.
Whether a 64 bit operating system and application would make a difference depends on whether it's really memory related, or if it's due to the internal data definitions (floats vs double for floating point numbers, etc). |
Post by Changa // Jul 27, 2007, 4:56am
|
Changa
Total Posts: 187
|
Thanks Lars, very interesting.
I think I rendered 16 4k x 4x pieces), while V-Ray does not like this at all, and rendering of individual pieces fail as soon as the total image size is on the order of 3k x 2k, just like everyone else is seeing.
Do you speak about distributed rendering on a single system or networking? And is it possible to alter TsNet for Vray and use it on a single system? A lot of questions:D |
Post by chamaeleon // Jul 27, 2007, 5:11am
|
chamaeleon
Total Posts: 74
|
Unless I specifically want to test rendering using multiple machines for some reason, I usually just use one machine, running both the controller program (usually in debug mode, invoked from the compiler) as well as trueSpace, I can see right away whether any issues pop up when loading scenes, etc. As far as tSNet is concerned, it doesn't really care how many machines are involved, or whether you're just running everything locally on one machine. Only caveat, as I mentioned earlier, is the fact that tSNet will only work with a single instance of trueSpace on any given machine. So I'm not really sure what you mean with "alter TsNet for Vray and use it on a single system" (as no tweaking of what tSNet does changes the overall render limitation currently present in V-Ray). |
Post by Changa // Jul 27, 2007, 6:40am
|
Changa
Total Posts: 187
|
First of all sorry for my poor english.Sometimes it does not reflect my thoughts.
Some respectable people in the previous discussions declared that in theory there is no limit in Vray rendering but the memory size. As far as practically for complicated scenes the limit is, I just wanted to say that it would be great to have an instrument to avoid memory limitations somehow and may be even to expedite rendering. I hoped that it can be done with program like Tsnet.
Thanks for replies. |
Post by Jack Edwards // Jul 27, 2007, 6:57am
|
Jack Edwards
Total Posts: 4062
|
Hi Changa,
The only way to alleviate the memory restrictions inherent in the 32bit software would be:
1.) Optimize the code for memory efficiency at the cost of speed.
2.) For VRay and TS to go 64bit and buy a #$%#load of ram ;)
Though it does look like you've come up with an interesting approach that would let people with more than 2 gigs of ram and 4+ cores be able to render animations more efficiently on 64-bit systems. Or have a render going on in the back ground while they continue to work on a separate instance of TS.
-Jack. |
Post by Changa // Jul 27, 2007, 7:17am
|
Changa
Total Posts: 187
|
Hi Jack,
Your words sound very simple and conclusive as usual. I like your style of writing :D |
|
