Build Your Own Render Farm

Another installment of Tom's Hardware's how-to articles has a look at what it might take to build your own render farm. The article looks at everything from top-to-bottom roll-your-owns to buying things pre-built and the pricing insanity that goes along with it. "If you are working as a freelance artist in the above-mentioned media, toying with the idea, or doing so as a hobbyist, then building even a small farm will greatly increase your productivity compared to working on a single workstation. Studios can even use this piece as a reference for building new render farms, as we're going to address scaling, power, and cooling issues. If you're looking at buying a new machine and are thinking of spending big bucks to get a bleeding-edge system, you might want to step back and consider whether it would be more effective to buy the latest and greatest workstation or to spend less by investing in a few additional systems to be used as dedicated render nodes."

Comments

Re:Unlatest

[i.r.id10t]

Unless they are very old, and power use would be better spent running fewer nodes with more rendering oomph.

The need is fading

[Anonymous Coward]

I would have been interested but I'm headed in this direction.

http://www.studiogpu.com/

It's still needs a few features but 90% of it will be added before the end of the year and it's a new release. They are even planning to support multiple video cards. Radically cheaper than setting up a render farm.

Re:The need is fading

[Trent Hawkins]

If I was to guess, non-linear probably refers to GI calculations. Global Illumination does take some time pre-calculate and a lot of things in those calculations are relative to the timeline so getting those pre-calculations done on a network so that the rest of the nodes can get access to it in a non-linear method does make a lot of sense. this goes fro particle and point caching too.
Also, if there's one thing that I've learned is that as hardware gets better, the demand gets higher. I can render stuff that I made five years ago that took days at the time in a minute but the scene is terribly dated and now I have scenes that look great but still take days to render, so I feel rather confident that in ten years, scenes will still take forever to render but they'll have hyper-atomic precision or some other crap to them.

Re:How to Jump Your Own Shark!

[jedidiah]

Both the last "bad idea" and this one really doesn't seem that far removed
form a lot of MythTV setups me and some of the users have. MythTV supports
a nice little cluster/farm setup where work can be shoved out to other
machines that are part of Myth. I have 3 frontend boxes, 2 backend boxes
and another desktop machine that can all share video processing duties.

Large disk arrays are not terribly unusual either.

Re:Ask a Slashdot Pimp

[Red Flayer]

Dear Slashdot Pimp,

I am a little confused as to your business plan. Why would you offer advice to slashdotters on getting laid on their own, when it would be far more profitable to ensure they need to visit your stable of hos to get laid?

Might I suggest you acquire the services of a business plan consultant to help you maximize your profits by leveraging the synergisms of your diverse talent pool? Careful attention to branding (perhaps literally) and marketing could help you achieve your quarterly and yearly targets for growth and margins.

Sincerely,

Slashdot Business Plan Consultant

4 Gig of ram is the max for 2 procs? WTF?

[BitZtream]

For memory, 4 GB is a good start. With the availability of inexpensive 4 GB kits (reviewed here), there's no reason not to. If you are using a dual-core processor and your renderer is a 32-bit application, then 4 GB means you'd have just short of the maximum RAM for each core (which is a good idea if your renderer doesn't multi-thread properly).

This is where I got off. I wasn't aware that dual core processors treated ram separately. Thats news to me, and the guys at AMD, Intel, MS, and Linus as well. Every OS I'm aware of bases the memory available on the app, not the core, with most 32 bit OSes allowing for about 3G of memory usable to the app (roughly a gig is part of the kernel space for various things in most cases), and allowing for more with some kernel tuning depending on the OS. I think Linux allows for that, I know Windows and FreeBSD do.

I also guess he's never heard of PAE? Last I checked pretty much every modern processor and OS was capable of supporting 36 bit addressing, meaning a process is more than capable of addressing vastly larger amounts of RAM if its designed to do so, and even without support directly in the application, you can run multiple processes to get the 3G or so per process, which with 2 processes you are at 6. So if your shitting rendering app is 32 bit, not PAE aware, single threaded and you have more than 1 core than you can just pile on more processes with any modern OS and exceed 4G of usage. With a real rendering app, i.e. multithreaded, PAE aware and still 32 bit, its a no brainer. Of course if you're going through the effort to do all this, what are the chances your renderer is going to be 32 bit instead of 64? This is a question I really do not know as I'm not a render monkey, but I just can't see anything that matters still being a 32 bit app unless RAM really doesn't matter in rendering, which lets face it, for a complex scene, it does.

Its good to know Tom's has some real techs working for him that understand how computers work.

Re:Playstation 2?

[fuzzyfuzzyfungus]

I don't think that there is anything stopping you(though the official PS2 linux kit is unsupported on the slim); but performance would probably be pretty underwhelming. 32 megs of RAM is an unpleasant limitation to labor under for a fair few computational problems, and(unless you are serious about doing optimizations to suit the PS2's particular hardware) you'll find that the stock general purpose processing power of a PS2 is pretty unimpressive.

Re:Thanks for this

[dr00g911]

The article neatly sums up how to build a render box from about 5 years ago, or for a hobbyist who doesn't really push the hardware.

In the last few years, with the prevalence of displacement mapping and linear workflow, file sizes and memory usage to get renders at the quality folks expect of CG work have skyrocketed.

As someone working as a freelance CG/VFX artist, I can tell you a few practical truths:

1. You may not need XP 64 but you need 64-bit if you hope to do high-resolution, or detailed renders in a single pass. An addendum to this is: don't even consider a motherboard that supports less than 8 gigs of ram, and max the thing out. If you are rendering under Windows, you're shooting yourself in the foot if you're stuck on 32-bit, in particular. You will hit a memory wall with a 4gb RAM system very very quickly. Linux 64 is fine. XP 64 (and even my tests with Win7 64 are good). Avoid Vista 64 like the plague.

2. Depending on your primary rendering usage, a Core i7 may actually be working against you with hyperthreading. Quite a few of the big boys (Renderman, Mental Ray) are still licensed per thread. With hyperthreading enabled on the motherboard, an i7 looks like 8 cores to many rendering apps. Relevant example: A dual quad Xeon Mac pro can only use half of the machine's processing power as a Mental Ray satellite node with Maya, because it's licensed to only use 8 threads total. In addition, a lot of compositing apps -- and LOTS of plug-ins -- are single-threaded (I'm looking at you, random After Effects plug-in, and just about any dynamics plug-in for a 3d app). The short of it: if you're going to be rendering with something that's actually capable of saturating a multi-threaded CPU, go for it. But do some research and tests first.

3. You might be able to get away with a crap mainboard video card -- but make sure of it. A few CG apps don't have command-line rendering available, and it'll suck to learn after the fact that the app you're trying to launch on your pile of new 1U servers won't launch because you don't have a decent video card. Linux & Mac OS (even Hackintoshes) are far superior to Windows in this regard -- you'll rarely find an app that refuses to run due to the card. Crap interactivity is fine as long as you can initiate a render.

4. Standardize your render boxes AND WORKSTATIONS on a single platform (ie Linux 64, Win 64, MacOS X 10.5 intel). Lots of apps require shaders to be recompiled per platform, and small studios generally use share/freeware stuff that might not be available on all platforms -- it's much better to work around this issue when you're creating your assets, versus when you've got a delivery deadline looming and you realize that your fancy layered shader looked great on your Win64 previews, but the code isn't available for Linux 64 to render within your lifetime.

Re:How to Jump Your Own Shark!

[anonymous donor]

Firefox + AutoPager + Adblock Plus + NoScript + Stylish and problem's gone. Yeah, browsing the web is a lot more complicated than it used to be...

Re:Part Time Render Farms are cool

[Rtfm42]

The software you're thinking of is Pixar's Alfred.