Using all cores on Raspberry Pi 2

I just upgraded to the Raspberry Pi 2, and I’m using the cross-compiling environment ( ) to develop with.

After running the ascii Video example on the old and new models, I’ve only noticed a nominal increase in speed (perhaps due to the increased clock speed). Is there some kind of setting when compiling that would cause it to use all four cores when running for better performance?

The nominal speed increase for that example is due to the processor speed increase. openFrameworks operates in a single thread (this is partially because OpenGL must be executed from the main thread of execution). A single thread will, by default only leverage a single core at a time. Without a technology like OpenMP (which automatically attempts to send easily parallizable tasks like loops into multiple threads), you’ll need to explicitly divide up your program into parallelizable parts that you can run in 4 or more separate threads (via ofThread or the like). This goes for any multi-core system.

That said, I’d imagine that there are many libraries, and addons that use multiple threads (e.g. ofxTaskQueue) that will demonstrate an immediate speed boost. As far as I know, the default ofVideoPlayer does not use multiple threads … unless the GStreamer codec you are using does (@arturo ?).

That said, I believe that ofxOMXPlayer and ofxOMXGrabber currently use multiple threads during execution, so you should see a performance boost using those. Perhaps @jvcleave can confirm?

Yeah - my addons do use threads but the performance gains are because they utilize the GPU/Hardware Video Decoding

I think the biggest differences will be

  • Better USB device performance (USB can tax the CPU pretty hard)
  • Improvements in copying/allocating/processing pixels
  • Anything that has NEON optimizations (although the OS may also need upgrades to support)
  • Being able to compile on the board (The Udoo compiles much faster than the RPI1 because of the extra cores/memory)

Thanks for the explanation. I didn’t realize there was an inherent single thread limitation due to OGL. I’ll tinker with the OMX components, but I’m hoping I won’t have to do any realtime video processing and it will be a moot point.

video decoding is not done in the cpu but through omx in the gpu both in ofxOMXPlayer and the default player when using gstreamer so there won’t be any gain from having more cpu cores in that area.

@arturo A little unrelated question, but I’ve been searching around for more info about ofxOMXPlayer vs ofVideoPlayer on the Pi.

I’m trying to make a project that will play video fine on multiple platform including the Pis. ofxOMXPlayer is nice but it just won’t play well on other platforms.

From your comment here is it right to imply that I can just use the default player and would get the same performance that ofxOMXPlayer does? Is there any difference between the two, or any difference between using master vs v0.8.4 release?

ofVideoPlayer in master is much faster if you set the pixels format to
OF_PIXELS_NATIVE cause it avoids the colorspace conversion in the CPU
but ofxOMXPlayer is still a little bit faster i think because it has the
option to not recover the pixels and just send the data directly to the