OpenMosix, Blender

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Post Reply
Devas73
Posts: 26
Joined: Wed Oct 16, 2002 12:21 am

OpenMosix, Blender

Post by Devas73 »

Hello,
looking in sourceforge to look for interesting projects I saw OpenMosix, a clustering kernel patch for Linux (it allows to build a cluster which behave liek a SMP machine using LAN connected computers, no need to use cluster-enabled libraries - just multi processed programs).
How much difficult would it be to add multi processing for rendering, maybe through a command line option in blender which allows to specify how many processes to spawn during rendering (ex. if I specify 2, when I render an animation blender spawns 2 processes rendering 2 frames at once)?
Maybe the network renderer is the most viable solution, since anyway no other processes can be migrated to other nodes in the cluster - this solution would also work on Linux only.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Re: OpenMosix, Blender

Post by thorax »

Devas73 wrote:Hello,
looking in sourceforge to look for interesting projects I saw OpenMosix, a clustering kernel patch for Linux (it allows to build a cluster which behave liek a SMP machine using LAN connected computers, no need to use cluster-enabled libraries - just multi processed programs).
How much difficult would it be to add multi processing for rendering, maybe through a command line option in blender which allows to specify how many processes to spawn during rendering (ex. if I specify 2, when I render an animation blender spawns 2 processes rendering 2 frames at once)?
Maybe the network renderer is the most viable solution, since anyway no other processes can be migrated to other nodes in the cluster - this solution would also work on Linux only.
I had access to a 4 processor SGI Onyx once, and how I got it to render for multiple processors was just to run the same program four times (in this case Wavefront TAV or Alias 8 ).

Note that this costs four times the memory, the machine had about 512 megs..

I figure this would be no different, but it doesn't offer you much control, and have to go around killing processes that run away with the CPU.. When you do a list of jobs on Unix you will see among the jobs on a Onyx numbers that indicate which processor the job is running on.. I'm sure this would be the case for this new kernel patch..

What would eb wrong with arranging blender as a number of client/servers across a network, using something else to farm out processes and then communicating the port/IP information
to the server, and distributing the render processes via IP..
That would be the most platform independent.. I guess this is
how blender does it now with the Network render.. Never have had much reason to use it because blender is so fast there isn't much need to use a network render. Unless you are in college and have advantage of all that free processing power going to waste.

SirDude
Posts: 233
Joined: Sun Oct 13, 2002 7:37 pm
Location: University of Minnesota (USA)
Contact:

Post by SirDude »

Just an additional comment. Ton mentioned recently
that it spawning the render off into another process would be a good idea and shouldn't be hard to do. Someone
just needs to sit down and do it. I believe someone else
also mentioned it would be nice to specify number of
processes to spawn.

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

Post by z3r0_d »

uhh, some more stuff

first: heard of knoppix?
"live linux filesystem on cd"
uhh, that means you can run it from cd

well anyway there is a version of knoppix with openmosix AND BLENDER

(have access to lots of computers?)

I was considering trying it in a computer lab I assist in (it will be empty next week and closed the one after), but I don't have time to burn > 100 cds nor use for that kind of thing.


back to the topic more-or-less
openmosix seems to try to seperate seperate threads onto different machines. For blender's renderer that isn't really useful. Also it renders quickly enough (usually) that the ideal approach would be to distribute the scene and have them render frames individually. The only problem that could be encountered with this or a similar method would be that dynamic simulations (there aren't any... yet) or non-linear python scripts would have to be precalculated, and the results distributed with the scene. (the same problem as ik in the game engine, it must be baked because it isn't done in realtime and there is no guarntee the animation will go foreward, or backward so it is baked so that it may be accessed in a random order without problems)

kAinStein
Posts: 63
Joined: Wed Oct 16, 2002 3:08 pm

Post by kAinStein »

z3r0_d wrote:uhh, some more stuff

first: heard of knoppix?
"live linux filesystem on cd"
uhh, that means you can run it from cd

well anyway there is a version of knoppix with openmosix AND BLENDER

(have access to lots of computers?)

I was considering trying it in a computer lab I assist in (it will be empty next week and closed the one after), but I don't have time to burn > 100 cds nor use for that kind of thing.


back to the topic more-or-less
openmosix seems to try to seperate seperate threads onto different machines. For blender's renderer that isn't really useful. Also it renders quickly enough (usually) that the ideal approach would be to distribute the scene and have them render frames individually. The only problem that could be encountered with this or a similar method would be that dynamic simulations (there aren't any... yet) or non-linear python scripts would have to be precalculated, and the results distributed with the scene. (the same problem as ik in the game engine, it must be baked because it isn't done in realtime and there is no guarntee the animation will go foreward, or backward so it is baked so that it may be accessed in a random order without problems)
Why not use bootp to boot a minimal Linux with Mosix and Blender? ;)
Most network cards are able to boot over the network. So no >100 cds needed! That's what many clusters do - the nodes just boot over the network.... :)

JWalton
Posts: 58
Joined: Sun Oct 13, 2002 7:39 pm
Contact:

Post by JWalton »

i used mosix for blender rendering years ago it works great. it works by PROCESS MIGRATION, so it most entire instances of blender, not threads. there are a lot of restictions. one of which was processes that utilize local i/o must migrate back to the machine that hosted that I/O. there were ways around it. but still, it was very useful (ie didn't have to use the renderd hack).

JWalton
Posts: 58
Joined: Sun Oct 13, 2002 7:39 pm
Contact:

Post by JWalton »

openmosix's DFSA (direct file system access) allows local file operations
on remote filesystems. this is a good thing. there was one routine in old
blender that did memory mapped I/O, I have to go through my old emails
to rememer what the problem was.... should avoid this sort of code in
future blender is possible.

I'm upgrading, and reinstating my old mosix cluster (mootron), if
anyone is interested in discussing mosix/blender related stuff I would
love it.

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

Yes, tell us more about the legendary mootron, please. I didn't realize it was a mosix cluster, just assumed it was a bunch of boxes shell-scripted together.

In these days of cheap $100 motherboards, rendering clusters seem more and more affordable. People living in cities can now realize their dream of owning their own (render) farm.

Did you find that i/o bandwidth across the network was a bottleneck?

JWalton
Posts: 58
Joined: Sun Oct 13, 2002 7:39 pm
Contact:

Post by JWalton »

apperently someone is working on the shared memory migation process
already! awesome!

http://mcaserta.com/maask/

stiv: in the begining it was a shell scripted bunch of peecee's, but with mosix it made it that much easier to start processes.

I use 100baset since the cheap motherboards only have 32bit 33mhz PCI
(remember this is from 4 years ago or so). i can cheaply channel bond
100baset networks now. ~6 bucks for DLINK DFE-530TX+ 10/100 cards.
only bottleneck was CPU speed for rendering :-) although some renders
exceeded the 32mb, then 64mb/per node i used. i've upgraded to 192mb
now, which i hope is ok. some benchmark rendering memory consumption
numbers would be nice to have.

there's so much to do with it, and so little time i have at hand... i would
really like to test out my old ideas about image rendering partitioning
first.

JWalton
Posts: 58
Joined: Sun Oct 13, 2002 7:39 pm
Contact:

Post by JWalton »

z3r0_d wrote:back to the topic more-or-less
openmosix seems to try to seperate seperate threads onto different machines. For blender's renderer that isn't really useful. Also it renders quickly enough (usually) that the ideal approach would be to distribute the scene and have them render frames individually. The only problem that could be encountered with this or a similar method would be that dynamic simulations (there aren't any... yet) or non-linear python scripts would have to be precalculated, and the results distributed with the scene. (the same problem as ik in the game engine, it must be baked because it isn't done in realtime and there is no guarntee the animation will go foreward, or backward so it is baked so that it may be accessed in a random order without problems)
thanks for jogging my memory, we had thought through those problems
before, eh :-) one solution is the xparts/yparts rendering idea (thanks Macke) where every node runs the complete render, only rendering a slice of the original scene, an assembly process at the end puts the images back together. one nifty sideffect is it's applicable to single frame rendering too.

and to anyone that thinks blenders render is fast, try that billiard ball animation of (darn forgot your nick, my bad) that was done a couple of years ago with motion blur and environment based lighting it took three days on the mootron then!

any more gotchas?

Post Reply