with one "r" or 2.
A proof of concept of a kernel composition utility, meant to break down the writing of cuda kernel into smaller pieces and examinate the rendering result of the combinations in realtime.
It's written with QT5 and tested with cuda v4 to v7. https://github.com/flintforge/baracuda/
GLSL sauce
A GLSL wrapper is included : with a few modifications, a GLSL code will compile. Not all, as the wrapper is fairly incomplete and don't expect performances with it : this does not generate machine code, but add extra structures, for the standard glsl functions, swizzles operations and vectors association/composition to work.
Build
$ qmake && make
note that if you qmake -project
, this will overwrite baracuda.pro
cuda setup
Check the hardware
lspci -v | grep -i nvidia
If your card is registred as a 3D controller, you'll need either to run bumblebee, or turn the GPU as primary device in your BIOS.
check the number id and go to supportedchips
For debian : https://wiki.debian.org/NvidiaGraphicsDrivers
Bumblebee project page : https://wiki.archlinux.org/index.php/bumblebee
For a fresh start on debian :
purge anything related to nvidia and cuda :
apt-get purge nvidia-* cuda-*
install nvidia-driver through the jessie backport :
apt-get install -t jessie-backports bumblebee-nvidia
Inspect any errors by digging into /var/log/Xorg.8.log
and kern.log
gcc setup
take note that gcc-4.7 and up aren't supported with cuda6 you'll have to install gcc-4.6 g++-4.6 (or 4.4 with cuda5)
troubleshoot
CUDA_ERROR_NO_DEVICE (no CUDA-capable devices were detected)
cuInit returned 100
either you're back to start or you forgot to run baracuda
with optirun baracuda
If running the rendering in a virtual framebuffer and that is the case with optirun – libqxcb will crash when dragging an item from the list to composer. For now, the workaround is to add the item when it's clicked
CUDA_ERROR_INVALID_CONTEXT
This most frequently indicates that there is no context bound to the current thread.
his can also be returned if the context passed to an API call is not a valid handle
(such as a context that has had cuCtxDestroy() invoked on it).
This can happen if you mix different API versions too (i.e. 3010
context with 3020 API calls). See cuCtxGetApiVersion()
for more
details.
How did it started?
Some idiot at the lab wanted to push further their Java code (they had a publication in Nature Method about that), but they were unable to figure out what should be done about large data acquisition, archival and sharing. All the project manager could do was getting all red and yell : "we are doing EJB here!". The glassfish server was consuming 2GB of RAM and leaking for who knows what (infinispan maybe?), and some memory was left for an hungry Eclipse. He still wanted to use that poor and aging ImageJ so bad… later the lab turned to Omero. The race was long over.
Digital Image Processing by W. Burger and M.J. Burge, Springer Ed. is in my library. It's not bad, and goes well along that software, because it's old. Too bad for them, because in a matter of 18 months and free hands I would have made, with love, something useful and ambitious.
BaraCUDA was the alternative project I coded to keep my sanity during that contract.
What to do next ?
If you're in need of a QT+CUDA setup, that's a start. Programs streams linked through pointers with hooks in between and on-the-fly compilation can provide great productive setup with quick code/eval/debug loops.
Coders like to program shaders because the result gets vizualised in realtime. To put it like Bret Victor does: it's about immediate connection.
You can also get into similar configuration with plain C++, instead of inserting a scripting language like Lua.
I moved to PureData since then, and never lost the idea that some day, I would do something inspired by this and by Gem.