After downloading the latest and greatest version of Blender, I decided to give it a spin in a virtual machine (Virtual Box). Blender is an open source 3D modelling tool with a complex architecture and a lot of dependencies. I typed blender into my commandline, and to my surprise it greeted me with a helpful message…
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM
How could it possibly know it was running in a virtual machine and how can I find out how it does this? Being open source, I trust it implicitly, but it’s always nice to know how these things work and discover where in the system it’s poking its fingers.
My first thoughts were to dive into the source code and see if I can find out where it’s detecting which graphics drivers to use, maybe there answer lies there. After having waded through the many of the thousands of source files with little success, I felt best to try a different approach to find out how this magic was happening. For this I turned to Breeze.
Breeze allows you to trace the internals of any software running on Linux. It’s function is similar to strace or ltrace, but it’s designed to be easy to analyse via coloured graphs and diagrams rather than a simple text output. It gives information about which libraries the software loaded, which files were read or written to and the environmental variables in play when each call was made. I decided to trace Blender and see if it could tell me what was happening. The results of my trace appeared in a graph showing the program calls (shown in orange) as well as the files it read (in pink).
From this cut-out section of the graph it produced I can see it loaded a library called vboxvideo_dri.so. This must be close to where it is detecting the 3D enhancement support in my Virtual Machine, but how did it know to look there? I decided to look at the Blender-bin process information for more clues.
From here I can see the base libraries loaded at execution time as well as the libraries loaded dynamically whilst blender is running. A lot of libraries failed to load, but none of those give me a clue. Amongst the dynamically loaded libraries I find my friend vboxvideo_dri.so, which in turn loaded 2 other libraries. vboxOGcrutil.so is almost certainly the library that detected that there was no 3D support from the host as we know Virtual Box provides its 3D enhancement support via OpenGL. So, from this I know that Blender isn’t aware of the 3D Acceleration Support, but the OpenGL libraries are.
Not surprisingly, Blender ran happily enough with this support turned off anyway and turning the feature on in the Virtual Machine made the message simply go away as expected.
So, I had found the root of my unexpected but helpful message and thought I would see what else Blender does at run time. First of all it runs ps to see what processes are running on the machine already. One assumes this is to detect whether or not a version of Blender is already running.
The other interesting procedure it performs is to check with dpkg, Debian’s package management system, which version of Blender it believes it has installed. Most software relies on a file called VERSION or similar mechanics for this; Blender simply checks to see what your package manager has to say. One has to wonder what would happen if you compiled a standalone binary. Watch this space….
Ellexus BREEZE Development Engineer
Ellexus are the developers of Breeze, a Linux dependency tracing tool that shows you what your programs are doing as they run. You can quickly search trace data to trouble shoot a problem build or installation.