(Amiberry powered) Lightwave render farm, pt 4

By | 2020-05-31
0 Comment

Next we need to install Amiberry itself. If you’re using the recommended Raspberry Pi OS, then you can use the pre-compiled binaries available in the Github Releases page. Otherwise, you’ll need to compile it yourself (check the instructions in the Readme). I recommend you install Amiberry in the same location for each machine, to make your life easier when managing all of them later on. I went for /home/pi/projects/amiberry in my example, but the actual path doesn’t matter as long as you have full access there. Just make sure you include all the directories and files included in the Release zip archive!

Amiberry needs Kickstart ROM files to work, just like all UAE programs. Just copy your kickstart ROM files in the amiberry/kickstarts directory. The filenames don’t matter, since Amiberry will check the files based on their SHA checksum values. If you have no kickstarts added, then Amiberry will automatically fallback to using the embedded AROS ROM, instead. The latest version of the AROS ROM is available in the Github Releases page, so you can use those instead, if you’d like.

Start up Amiberry once, to ensure that everything works correctly until here. While you’re at it, go to the Paths Panel and click on the Rescan button. This will trigger a (re)scan for Kickstart ROMs, which will be detected and cached, so they can be chosen automatically when you select a configuration from the Dropdown menus.

With Amiberry ready to run, it’s time to copy the RenderNode virtual HDD in a location where Amiberry can use it. I chose to place it under amiberry/dir/rendernode to keep things simple and organized. Remember, you’ll need this in all your Raspberry Pi devices that will be running Amiberry!

Once we’ve done that, we can now create a new Configuration in Amiberry, to hold our settings for booting this RenderNode environment. In general, we want the fastest CPU setting possible, JIT and JIT FPU enabled, as much RAM as we need for our Scenes (some can be very demanding!), while we don’t really care about Sound emulation or Collission detection. Here are the settings I used, per Panel (screenshots taken from v3.2 beta, current version might be slightly different):

CPU and FPU Settings: As fast as possible, with JIT enabled. The CPU Idle slider is a new feature in v3.2, which allows the emulated CPU to throttle down when not in-use. This helps to keep the temperatures down!
Chipset Panel: Set it to AGA, no Collission detection needed, set Blitter to Immediate to speed up the redraws. The Fast Copper setting doesn’t really matter either way, since Lightwave doesn’t use it.
ROM Panel: You can pick a Kickstart ROM v3.1 for the machine you’re emulating (in my case, an A4000), or the open-source AROS ROMs instead.
RAM Panel: The default 2MB Chip RAM is enough, and as much Z3 Fast as you might need. I went for 512MB in my case. If you have a board with more than 1GB of RAM, you can allocate up to 1GB of Z3 RAM!
Floppy Panel: Just the defaults here, we won’t be using any floppies anyway

The most important part, is the Hard drives panel configuration. We will need to add 2 drives here: The RenderNode one, which will be the bootable first drive (let’s call it DH0:), and a second non-bootable drive (DH1:) which should point to your shared content directory. The second drive should be named Projects: if you don’t want to make any changes in the RenderNode assigns. In my case, it’s mounted under /cifs/koula.midlair/Projects:

Hard drives Panel: Add 2 drives here, one is the RenderNode bootable drive (DH0:), the second is the “Projects:” shared content drive (DH1:)

Note: You might need to manually access the shared content directory once, to get autofs to mount it, if you don’t see it when browsing for it with Amiberry. Just try something like ls -al /cifs/koula.midlair/Projects (obviously, change the actual path to match yours).

Display Panel: Width and Height are OK with 640×256, since we won’t be running Lightwave itself from here. Horizontal and Vertical centering are nice to have, and if you want the maximum speed you can also enable Frameskip.
Sound Panel: We don’t need any sound emulation, so just disable it.
Input panel: We won’t be needing any joystick emulation through the keyboard, so set Port 1 to None.
Miscellaneous Panel: We don’t want the GUI to open up when we run Amiberry with this configuration, so we can disable that. If you want network access from within AmigaOS, you can also enable “bsdsocket.library”.

You can leave the Custom Controls and Savestates panels, as we won’t be changing anything on them.

Configuration Panel: Don’t forget to save your new configuration, with a meaningful name!

Go ahead and test starting the emulation with this configuration. If it all goes well, you should end up with ScreamerNet starting up and complaining that it cannot find any job to do…

The RenderNode boot environment, waiting for a new job. In this example, I’m using the Commodore ROMs, the AROS ROM environment would look slightly different.

If it all went well until here, congratulations! The hardest part is done. Now you can copy this configuration to all the other Raspberry Pi boards, along with the RenderNode files. Just make sure they are placed in the same path on each device, so that the configuration will work everywhere without modifications.

As an added bonus, once you’ve tested that your “rendernode” configuration works as expected in Amiberry, you can have the emulator start it up automatically. Amiberry looks for a configuration filename named “default.uae“. If it’s found, it is loaded automatically on startup, with no user interaction. If you have set your configuration to not show the GUI, then it will also boot immediately. So if you rename you configuration to “default.uae” instead, you can simply call “amiberry” and it will load and start your rendernode, just like that!

We’re almost done now! In the next part, we’ll be looking at how we can put all these parts together, and do some real rendering!