GPUs, OpenCL, and You

Let talk about OpenCL. 

It’s the driving force behind all of the solver’s number crunching. The solver’s custom sparse volume data structure is written in C++ and has an API that lets OpenCL work with it’s data. This is how the solver can be sparse and run on devices like GPUs.

However, GPUs and OpenCL can be a bit temperamental at times. When it works it works really well and will shred through data like it’s nothing if you have a decent GPU. When it doesn’t you are stuck trying to figure out what is going on with drivers and such. 

Here are a few things to keep in mind about GPUs, OpenCL, and you

The first and the easiest thing to talk about is memory allocation. When you use the solver you are explicitly setting the maximum number of voxels the solver can use and when the solver initializes it will allocate the memory on whatever device you have chosen. By default this is your systems GPU, failing that it will use your CPU. When you select a number of voxels the solver will show the amount of memory you need with a text label right below the voxels parameter. However, just because you make have an 8GB GPU does not mean all of the memory is available for use at that exact moment. The GPU needs memory for showing geo in your viewport and other tasks as well. It is important to keep this mind and some GPU manufactures and OS have tools to show how much memory is being used live.

Next is what happens if you request a certain amount of memory and your device decided it can’t do it. In that case, by default, the solver will fall back to the next best device in your system. It will first look for another GPU, but in the event you are a mere mortal and don’t have multiple Quadros in your system hooked up to your 9 8K monitor rig then the solver will use your CPU as a fallback. This usually always works because you will probably have more than enough system memory.

Lastly, we have an Nvidia quirk. Sometimes, for some reason, Nvidia card just give up and will spit out -9999 OpenCL errors. When this happens restarting Houdini usually does the trick to fix it. I’m still not sure why this happens as it’s rare enough that I can’t find a reliable way of making it error for debugging purposes. 

I hope that helps explain some of the common OpenCL weirdness you can get and what it means.

Matthew Puchala