[Bf-committers] x- and y-parts

Jeroen Bakker j.bakker at atmind.nl
Fri Jun 26 11:18:23 CEST 2009


Hi all,

I was wondering what functionality the x-parts and y-parts in render 
settings have besides the obvious.

Since last year the number of software threads are calculated from the 
number of hardware-threads. Still this value can be altered (Thread Auto 
detect/fixed). The x and y parts divides the frame in a frame segment 
and a thread renders a framesegment. When the framesegment is finished 
the thread will render the next framesegment until the frame is finished.

Issues:
1. When a scene is rendered on a cluster the x-parts and y-parts limits 
the number hardware thread that will be used.

2. When reaching the end of a frame, the number of idle threads will 
grow. Blender first want to finish the frame, before continuing to the 
next frame. The total idle time can be minimized by increasing x-parts 
and y-parts, but it is not a solution to the problem.

Proposal:
1. limit
I think we should separate the infrastructure and the really blender 
related stuff. What is against calculating the value of the x-parts and 
y-parts by the number of software thread.
Something like:
x-parts = y-parts = ceil(sqrt(number_of_thread)*factor)

"Factor" can be configurable by the user/or a setting in the infrastructure.
with a factor of 1.5 and 2 cores
x-parts and y-parts will be 2 (so 4 segments)

2. when rendering an animation, why do it frame for frame. When the 
prepare of frame 1 is ready, the frame can be rendered and the prepare 
of frame 2 can start in parallel. I expect that the idle time will be 
reduced and the "factor" could be a constant. Does GoSC look at this 
subject?


A 3d artist can always use render preview (Shift-P) to just render some 
part of the frame he wants to check. and not think about the 
infrastructure related settings.

Or do I mis something?


More information about the Bf-committers mailing list