[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