Recomendation : Speed Improvement, by Practicality (2.42)

Blender's renderer and external renderer export

Moderators: jesterKing, stiv

Post Reply
deal_maker
Posts: 0
Joined: Tue Jan 04, 2005 1:37 am
Location: Autralia

Recomendation : Speed Improvement, by Practicality (2.42)

Post by deal_maker »

I had an idea as I saw blender render:

In multi threded machines (multi-core) each core is assigned different parts, what if one core finnishes before the other and the other core still has one or more parts to go? Couldnt the now dormant core take over? Wouldnt this speed up rendering? Especially in Animations? Im not sure how the coding side of this looks, but I thought it was just an idea, as it happens to me a lot that one core finnishes and has nothing to do while the other is still working...

Any thoughts?

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

I think it's a must and I hope to see it in the near future.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

Lynx3d
Posts: 0
Joined: Tue Jan 24, 2006 5:09 pm

Post by Lynx3d »

Eh...i don't think the other thread has ever more than one part to go, because each thread gets a new part when finished with one until there are none left.

Turning up the x-/y-parts decreases the time only one thread is active, though to me it seems there is a considerable overhead with each part...on the scene i just tried render times actually get worse when going from 2x2 to e.g 3x3. (dual Athlon MP 1800+)

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

When only one part is left, that part must be splited betwhen the available processors to get a smart and fast rendering.


I like very much the way Cinema4D solve that thing:

C4D split the whole screen by the half and asign each to an processor, every time a part is finished, the remain part is splited again at half size.
This way the processors are at 100% all the time until the last line is rendered.




Sorry by my poor english.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

mpan3
Posts: 0
Joined: Wed Mar 24, 2004 7:16 pm

Post by mpan3 »

actually i think the current fixed-tiled-based-rendering is very good. the performance gain from switching to C4D's method will be minimum as blender 2.42 already assigns the idle thread a new tile everytime it finishes one. To solve the 'last tile' problem, simple crankup the tile X and y part a bit and this should effectively use (almost) all the cpu time.

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

mpan3 wrote:To solve the 'last tile' problem, simple crankup the tile X and y part a bit and this should effectively use (almost) all the cpu time.
If I undestand what you mean (increase the x y parts?) thi's not a good solution, because Blender become more and more slow every time you do more parts.

Try render someting with 4x4 parts and later try the same scene with 16x16 and compare render times.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

mpan3
Posts: 0
Joined: Wed Mar 24, 2004 7:16 pm

Post by mpan3 »

Caronte wrote:
mpan3 wrote:To solve the 'last tile' problem, simple crankup the tile X and y part a bit and this should effectively use (almost) all the cpu time.
If I undestand what you mean (increase the x y parts?) thi's not a good solution, because Blender become more and more slow every time you do more parts.

Try render someting with 4x4 parts and later try the same scene with 16x16 and compare render times.
...and you think this won't happen with C4D's progressive refinement approach? Any rasterizer is most efficient at rendering the image in a coherent order: from top to bottom and etc. Any splitting of the image into parts will induce an inevitable overhead cost, thus affect the performance in a negative way. The best solution would be for each logical processor to get its own frame to work on, this way, CPU0 will be rendering frame 1 while CPU1 is rendering frame 2 and so on...

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

mpan3 wrote:...and you think this won't happen with C4D's progressive refinement approach?
No, not happen, because the refinement occurs only when one processor is idle. This way if far more eficient.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

Ammusionist
Posts: 0
Joined: Thu Oct 30, 2003 7:34 am

Post by Ammusionist »

Caronte wrote:
mpan3 wrote:...and you think this won't happen with C4D's progressive refinement approach?
No, not happen, because the refinement occurs only when one processor is idle. This way if far more eficient.
No - Back up and have a think about what you're saying here...
The picture gets divided in half and two processors work on the two halves.

When one finishes - there is NO remaining half - it's already assigned to the other processor UNLESS you're suggesting Blender should HALT the rendering process of the second, THEN divide the unrendered portion in two THEN reassign each processor to the two new sections?

That's going to take a huge hit!

Better to have some regular unrendered tiles already allocated and ready for an idle processor OR preprocess the image into tiles according to complexity (Don't ask, I don't know how) and then assign them progressivley to idle processors.

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

Ammusionist wrote:That's going to take a huge hit!
Ok, I can't speak english very well so I don't want to make circles with the same music :roll:

My experience with 3D apps is huge (since 1985) and I know very well what I'm talking about, but I can't explaint it better in english.

The fact is:
C4D render at 100% of the processors until the last pixel is rendered and Blender not. period.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Post by z3r0_d »

Caronte wrote:The fact is:
C4D render at 100% of the processors until the last pixel is rendered and Blender not. period.
actually, 100% processcor usage does not mean the cpu is being entirely used, nor does it mean it's being effectively used

100% processcor usage could mean 90% of cpu time is spent waiting for reads/writes to ram to complete.... It's hardly a reasonable measure

[but anyway, there's nothing but technical issues stopping multiple threads from working on the same pixel]

Caronte
Posts: 76
Joined: Wed Oct 16, 2002 12:53 am
Location: Valencia-Spain-Europe

Post by Caronte »

z3r0_d wrote:actually, 100% processcor usage does not mean the cpu is being entirely used, nor does it mean it's being effectively used
Otherwise a 50% of processor usage (like Blender does at last part) mean that you are wasting your time, for sure.
z3r0_d wrote:100% processcor usage could mean 90% of cpu time is spent waiting for reads/writes to ram to complete.... It's hardly a reasonable measure
:shock: :lol:
I'm talking about an optimal machine to render (without ram pagination), not a spectrun 48Kb.
z3r0_d wrote:[but anyway, there's nothing but technical issues stopping multiple threads from working on the same pixel]
No one said nothing about work on the same pixel.
If a thread have 10 raster lines to render but another processor is idle, nothing prevents to assign a new end (line 5) to finish this thread and then assign a new thread (with the remain 5 lines) to the idle processor.
Caronte.
"Some Day, All Will Be Digital"
http://www.nicodigital.com

Post Reply