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.
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.
No comments:
Post a Comment