[Bf-committers] Re: Blender and OpenMosix... does it have any sense ?

[GSR - FR]

Hi,
ton at blender.org (2005-02-08 at 1341.38 +0100):
> As a starter; multi-processes is different from multi-threaded!
> What I coded right now is 2 threads using shared memory, and is still  
> heavily scanline-based, and is very difficult to extend to more than 2  
> CPUs even. What I've aimed for is support for artist's workstations, it  
> is not likely 4 or 8 CPUs will get to the desktop anytime soon. :)

Dual core chips seem to be on the catalogs for current year, and some
can be used in dual socket main boards, so 4 "things that run code at
the same time" is not far away. There is multithreading too, so 4 and
maybe 8 or more. Chip makers seem to be going "wide" with the designs,
do more per cycle, instead of just more cycles. There are some
articles about this, and if they pass from speculation to facts, apps
will have to change (IMHO, they already should, disk, memory or
network are not speeding up at the same pace, so be IO bound and you
are toast).

Speaking of which, has anybody tried Blender with a multithreading
CPU? Is it worth vs single threaded and heat problems? I am talking
about Intel and the HT workaround for going mad with GHz.
 
> I also consider Blender still an animator's tool, so a render system  
> (cluster) can also be based on the assumption you need to render 100s 

And for still frames, there is always the option of dicing the image
and render it in parts. Maybe this would solve the problem of going
beyond 2 threads: do single thread part (radiosity, etc), split in
block of 64*64, or 100*100 pixels (something small to get many but not
too small that lots of time is used in passing things around) and put
threads to finish one block each, until all the blocks are done, then
do the final single thread part (halos, etc).

If those blocks could be defined as a state that can be loaded and
rendered directly, it could even be multiprocess (for local or
cluster, the trick would be worker jobs that adapt to each moment).

> of frames. There are many different projects going around on network  
> rendering, with drqueue being one of the more visible/working projects.  
> I still hope people can start cooperating a bit on this topic, having  
> (like now) 5 completely different approaches doesn't help us well.

BTW, DrQueue seems to be finally support MSWindows. So no excuse about
"Unix only" now.

GSR