Thursday, July 07, 2011

How to make Wyse Winterms into a Blender Render Farm for Animations

Setting up a Blender Animation RenderFarm with Wary Puppy Linux, a (large) handful of Wyse Winterms, and (more than) a few hours' work.




What to do with old machines? Convert them into supercomputers. That's an old scene and solution, but it's become more of a challenge, particularly as the hardware and Linux distro's advance beyond supporting legacy machines. I've been wanting to do this for many years, but either the software or hardware never made this economical.

It's the breakthrough of Wary Puppy Linux and Blender which has made this possible. Until recently, you mostly had to render with POVray over paralleled clusters, or invest in big machines with proprietary (read: expensive) software to do any of this. But since there are so many decent machines sitting around these days, being outmoded long before they actually wear out, it has become more and more possible to create actual home-grown renderfarms. This gives us a widening window of being able to get into entry-level animation with cast-off hardware, as long as we can still support the legacy environment.

The situation was that I had been given 5 Wyse Thin Clients, 9450xe to be precise (more data here: http://parkytowers.me.uk/thin/Wyse9450XE/) These have built-in everything with 256mg RAM, 2 USB slots and networking. A low-power VIA chip, plus the use of 512 mg Flash for storing the embedded OS makes power consumption (and heat-generation) really low. So they are a quiet and cool-running machine, if limited. Ideal for a renderfarm

Of course, they are supposed to be run by accessing a server. And my first work at this was to try to replace their native Windows XP SP1 OS with Debian Linux (as per http://www.x95.us/winterm/9450/iso.php). Unfortunately, despite many attempts, this simply didn't work. Instead of working to find out what in the script wasn't working, I instead opted to simply replace the WinXP OS via a CD-boot. Fortunately, the WinTerm allows both USB CD and USB flash drives to work as boot devices - and I had both, along with some extra RAM DIMMs I'd salvaged from other old machines I'd recycled.

While I had several OS versions available, only Knoppix 3.6, Puppy Linux 5.25 and Wary Puppy 5.11 would actually run on this hardware. Lubuntu should have been small enough, but wouldn't even start up. Additionally, I tried the current and an earlier version of dynebolic - since this uses OpenMosix to create an instant cluster - but neither would start up.

Knoppix and Puppy Linux wouldn't install, however. Knoppix wouldn't install into such a small drive, and there was some problem with GParted under Puppy Linux being able to convert the file-system in order to run. Only Wary Puppy would install. (Again, I hold that use of the Ubuntu base has taken it away from some legacy support in favor of bells-and-whistles of the newer hardware.)

Next on the renderfarm planning was to install blender, as this is possible to do distributed computing - and it's even built into the current edition. I followed http://www.murga-linux.com/puppy/viewtopic.php?t=37749 and http://starbrightillustrations.com/blog/2009/11/09/how-to-enable-video-hardware-acceleration-for-blender-in-puppy-linux/ to work out how to get this installed - plus a ton of trial and error.

The key point is that a lot of the files in the X-org display scripts which are needed to support Blender weren't there, having been stripped to make it smaller. These above links show the basic route, though.

The essential path seems to be getting X-org basics reinstalled first, then install the dependencies Blender needs, then Blender itself.

I found that under the Setup menu (or Wizard Wizard) is an X-org update. If you opt for the DRI install, which is a download - so you have to connect to the Internet via your network or directly to get this. It tells you to reboot X-org, but just hold off until you install OpenGL first. You also want to make sure you are running at 24-bit video, as Blender needs this per report (although it will run in 16-bit).

In Blender dependencies, the only python I found would load is the 2.5.1 version. The other suggested files were fine (skipping the DRI file as above.) And this trial and error wound up too often with X-org giving me only a black screen on restart - with no way to save this except re-boot from the CD.

Eventually, I worked out the system that resulted in Blender being able to start.


The next was porting this to the other machines. Fortunately, there is a built-in, genius program which allows you to re-master the ISO based on your current installation. So I didn't have to arduously re-load all these .pet files every time. Simply create a new Wary CD and boot from this.

And so I then got all five machines pretty identical, and needing only a large switch to connect them all up as "headless" machines for a cluster.

While I was waiting for these various installs, I continued to research getting Blender to make an actual renderfarm. And of course, many people had been there, done that. While Blender 2.58 integrated distributed rendering, it's missing before version 2.5. As the Wary Puppy version is 2.48a, I had to find a script which would do this work.

(The point of doing this is to keep this as simple as possible. Since Blender is capable of doing animations and even games, this is a simple choice to make instead of spending thousands I don't currently have on proprietary equipment and programs. That is the point of using Wary Puppy, legacy hardware and open source programs. The idea is to get machines to get my work done at the bottom end of the financial spectrum. Once I "hit the big time", then it will be obviously time to get some of these dual and quad-core machines which should shortly be very cheap as they become "yesterday's news". The emphasis is to work with what I currently have available and to work smart, not hard.)

One renderfarm script called "FarmerJoe" came up in searches. Even though relatively new and un-involved, it has been used commercially with success. And has some mention on the Internet as the single tool to get. A review of similar tools either showed them to be pricey (more pricey than "free" anyway) or more complicated. (See http://mos.futurenet.com/resources/3dworld/TDW94.s_farm.pdf Also, this forum: http://www.openworldfilm.com/Forums/viewtopic.php?f=29&t=569)

Now, while I don't actually have some material waiting to be rendered, this basically sets me up to go. Success!

Additional notes: 
1) In studying up on FarmerJoe, I find that you don't actually have to install a version of Blender on each machine. It has it's own bin files for Windows, Linux, and Mac OSX. In those cases, I'd simply create bootable USB drives with Wary Puppy on them for each machine. Although the current scene of having Puppy already installed frees up their smallish RAM for rendering. I may have to consider USB files for extra swap space, although this will be determined with actual use.

2) Obviously, booting to Puppy on a machine with several Gigs of RAM would be a very simple approach to a renderfarm. Running FarmerJoe on the master node would then set up untold resources on the clients/slaves with very little time expended. Essentially, you could get a pallet of computers at some auction and simply check to see if the run and would boot off a USB stick. With a set of network cables and a decent switch, you'd have a simple renderfarm within hours of getting that pallet home. (Otherwise, another few hours loading in puppy linux after reformatting their HDs, etc. Even machines without HDs might be able to simply run off USB sticks...

3) I found it easier to simply reformat the file system when upgrading Puppy. Reason is that it would load in the last warysave.sfs and so not recognize the programs and drivers, etc. on the CD. So a fresh install from the tailor-made CD turned out to be the fastest approach. Since Wary actually mounted the drive and wouldn't allow changes, I had to use Knoppix 3.6 to do the reformatting (as it was an available tool and some of these other tools wouldn't actually even start up on these legacy machines.)  And there's probably a workaround I'm not aware of, like the F2 and F3 options for booting...

- - -

The screen-capture I made and saved over the network got lost in a half-terabyte, networked hard-drive. Of course, I stumbled on it later. Very nice screen capture utility.

And I have to get back to the point of having something to render next. So the boxes are all put away again for now (and thanks to my nephew Nolan who was patient with all this rebooting and figuring.)

Best of luck with your own trials.

[Update: 17 Feb 2014]

Got them all out a few months ago - and none would start or get past post. They all got recycled.

Great experiment, though.

Probably invest in some quad-core machines and RAM next time, or several. Price on surplus boxes is incredibly low. With tablets becoming the rage, they'll probably drop to much lower.

Again, I have to have some content which can get rendered to make this worthwhile.
Enhanced by Zemanta

No comments:

Popular Posts

Blog Archive