Building a Many GPU LTC rig

 I acquired most of my BTC gear through eBay (only a couple of Hashbusters directly from Ukraine and a Single while BFL had them on sale). They cost a premium there, but it was fun playing around with the variety of gear. I have resold most of the things by now and received a note about strange power usage from Simply Energy. I wanted to save myself some trouble and get an LTC rig off eBay, but the prices seem not worthwhile. The description of the rig is generic, almost like a pre-order, the seller is offering to build it for you assuming you cannot handle motherboards and pci-riser cards.

So I decided to have a go and thanks to the numerous guides and forum posts, setting up a rig with 2 GigaByte AMD 270x cards was a breeze (opencl calls them pitcairn). The 270x's are power hungry, taking about 200W each, you will need at least a 600W PSU with 2 cards to keep up. Get a modular PSU and will come in really handy in keeping all the cables neat and tidy and switching to powered PCI-e riser cards. I was planning to build a 4+ cards unit, so I got the Corsair RM1000 PSU.

Next was the choice of a Motherboard, it ended up getting the MSI Z87-43 with 2 x16 slots and 2 x1 slots usable with risers. In retrospect the Z87-45 would have been a better choice since it can handle more PCI cards or the made for BTC ASRock H81 pro BTC. After that there are behemoths such as the Trenton PCI host board with 18slots.

Getting the AMD Catalyst Drivers installed on Linux is a major pain. Finding the right patch requires some searching, but in the end it works quite nicely. After getting 1 machine working I imaged the SD card using win32diskimager and set up other motherboards I had lying around to run the same config. Just as I got going I realized that with the advent of ASIC's the supposedly ASIC resistant scrypt mining is now beyond GPU's time to look into vertcoin or dedicate these to Folding@Home.

Meanwhile if you are still playing with Scrypt based altcoins check out wafflepool and my Android widget to keep tabs on it.

Building faster Bundler with CPU/GPU parallelism

The initial Bundler release caused quite a stir allowing simple bundle adjustment from random collection of photos. It leverages the sparse bundle adjustment - SBA created by Lourakis. However being totally single threaded it does not scale quite well to large images. Sift point finding can be accelerated using SiftGPU - Changchang seem to have moved to greater things at Google since his PhD and academic research days.

I have built bundler for Windows 64 bit + CUDA as the MCBA documentation suggests. A few flags are not supported as shown below.
    CHECK_PARAM_SUPPORT(explicit_camera_centers == false);
    CHECK_PARAM_SUPPORT(optimize_for_fisheye);
    CHECK_PARAM_SUPPORT(use_constraints);
    CHECK_PARAM_SUPPORT(use_point_constraints);
    CHECK_PARAM_SUPPORT(fix_points);


I am calling it PBA_Bundler, please give it a try and let me know if it makes bundle adjustments faster for you. The GPU has higher error rates on floating-point calculations and can lead to large bundles drifting off reality. Even computers can have optical illusions. CPU parallel version has less error rate and yields more stable bundles. I am currently working on adding pthreads based parallelism to match filtering stages of Bundler (computing Epipolar Geometry and establishing bundle bounds) and removing the constraint in multi-core bundler which prevents the use of camera constraints.

OTB-GPU and Amazon AWS (Cuda Enabled) - Cloud Processing

A while ago OTB did some experiments running image processing code on GPU's. It has not made it to mainline yet since we are waiting on ITK to add more structured and pervasive support for GPU's in their infrastructure. I though it would be a nice bit of code to test the not-so-new but still shiny Amazon AWS Cuda support.

The preconfigured instance with Nvidia CUDA toolkit installed runs CentOS 5. You will need additional repositories to grab goodies like cmake and mercurial to get going, from RPMForge. You will need lots and lots of version controls e.g. subversion and mercurial, even compilers. I should have started from the GIS AMI.Getting GDAL installed as a dependency can be slightly tricky, the CentOS packages from ELGIS did not work form me, lot's of missing dependent libraries. Best bet is to install from source. Then use a small hack to copy over some headers and build OTB.

Build servers like Hudson can easily make use of such an image on AWS once configured with the right version control, configuration and build tools. I will have to test drive the Hudson CMake support with this instance. Otherwise I have been playing puppet master at home with Virtual Box and real hardware. I got the swarm plugin to register most my available platform to hudson as a build slaves, including the BeagleBoard. AWS can be accessed via a similar cloud/cluster plugin. I found the VirtualBox plugin rather cryptic, I think I will have to use the source for that one - it can be very useful for multi-platform installer and GUI testing, even recording instruction videos by playing through a UI test suite. Especially when using bootstrappers, errors are not detected at compile time. They only become apparent when the program is run on a clean system. Having a set of clean virtual machine snapshots makes it much easier to track down the error before it is released into the client base.