NGC 5679 Galaxy Group

I recently came across the Thrust library when I was toying around with Cuda. In that post I mentioned, “Assuming I can come up with a suitable application, I’m anxious to dig more into Cuda, Thrust”. The project I’ve set out for myself is a Cuda implementation of an N-Body Simulation.

These simulations yield some gorgeous results, and can be solved efficiently using a Barnes-Hut tree. There are already a few different implementations to reference. This obviously isn’t novel, but I have some ideas I’d like to pursue outside of a simple simulation. I’m not going over those here because I’m not sure how feasible they are.

This post is the first of hopefully of several that outline problems and solutions I come across while create a visually interesting simulations.

You can see the source code here.

Thrust Makes Management, and data Initialization Easier

The goal for this first iteration was to create a large number of bodies from a uniform distribution and save a PNG image of them. I wanted pixels with more bodies mapped to be rendered brighter than other pixels. So I needed to count them up.

In order to do this I needed to create a vector with as many cells as there would be pixels in the final image initialized all zeros. A cuda version of this might look something like.

That’s a lot of work before we even start creating the sums. This doesn’t even include the kernel code for initZeroes. There are multiple opportunities to mismanage memory: if the type of pixelBodyCounts is changed, there is a possibility of not allocating the correct amount of memory. We might accidentally delete our cudaFree statement, or attempt to use the data after it’s freed.

Now check out the Thrust version.

Much better! The data type can now be specified changed without worrying about misallocation. Deallocation will happen automatically when pixelBodyCounts goes off the stack. Finally the thrust::fill initializes the data without needing to write a custom kernel function.

But what about structs?

We’ve already seen how easy it was to create vectors of scalar values with Thrust. Creating vectors of structs ended up being pretty simple as well.

There are two different constructors. One without arguments Body(){}; is used when allocating the vector. Another that allows the component values to be set within a custom kernel. The Body constructors have been annotated as __host__ __device__ so they can be allocated on either processor.

Mapping Bodies to Pixels: Sometimes you need the raw pointer

It’s not always convenient to work with Thrust vectors and algorithms. When calculating the number of bodies for a given pixel, I needed to perform an atomic add operation. Cuda provides an implementation that works with memory addresses. I wasn’t able to figure out how to use Thrust vector references with this function, but it ended up being pretty simple to get a raw pointer to the data.

The pixelCount.data method returns a thrust::pointer which is then converted to a raw pointer.

The mapBodyToPixelCounts operation takes the raw pointer as a first-order argument . When called via thrust::for_each the function has access to the pixelCount pointer and a reference to the current body. Now we can pass the address corresponding to the pixel occupied by the body to Cuda’s atomicAdd function.

Casting to raw pointers is a little messier than working with the vectors, but sometimes it is the easiest of best way to work with an existing library.

From Pixel Counts to Pixels

After counting up the number of bodies in each pixel, it’s time to map those counts to an RGB pixel. In this case, we’ll be creating a gray-scale image. To do this we’ll need to map each pixel count to three channel values each.

The image vector is type unsigned char, this type is compatible with Open CV Matrix container, which we’ll use later on.

The index_sequence_begin iterator is used by the thrust::for_each function to deliver a sequence of numbers from 0 to PIXEL_COUNT to the different kernel tasks. I couldn’t iterate over the pixels directly because I needed to map the indices to a larger vector.

The need to change indexes meant that I couldn’t easily use the thrust::device_vector. So, mapPixelCountToRGBA takes raw pointers as first-order arguments. These pointers are accessed by indices calculated using the BODY_COUNT_GRAYSCALE_RATIO constant.

From **device_image** to Image File

Now that we have a device_vector of channel values, we need to save them to a file. The solution I came up with was a three-step process: copy from device to host, copy host vector to OpenCV matrix, and then save the matrix to a file.

First I needed to copy the data from the device to host. This is made easier with Thrust.

Next, the image data needs to be copied to an OpenCV Mat. Then saving to an image file is easy.

This is a little nastier. The matrix has to be initialized with the image dimensions and the channel format. I also needed to dip into raw pointers again and provide the memory size. I hope to find a way to do this with iterators later on.

The [cv::imwrite](https://docs.opencv.org/3.1.0/d4/da8/group__imgcodecs.html#gabbc7ef1aa2edfaa87772f1202d67e0ce) function is really easy to use. It can save to many different formats, and switching between .jpg and .png is as easy as specifying a different output file through the command line.

Below, you can see a gif of several images produced by this iteration of the program.

Animation of multiple uniform random distributions. (Very exciting)

Conclusion

That covers all the things I found noteworthy while working through this first iteration. I hope to report back with bodies that actually interact soon!