Raspberry PI 2 released

The Raspberry PI 2 Model B is now available. And it is fully compatible to the previous Raspberry PI versions. Here is how this is going to affect info-beamer.

More cores

The new PI has a Cortex-A7 quad-core processor. So in theory things could run a lot faster. Right now info-beamer can only make limited use of those new cores: Your visualization is most likely limited by the GPU and its memory bandwidth. So having more CPU power won't help in that case.

But additional cores also help: Since info-beamer 0.8.2 all resource loading is now offloaded to background threads. So loading images or playing videos can now be completely done in the background with minimal effect on the current framerate.

I'd be happy to hear from you. Did you get any speedups from the new Raspberry PI 2?

Running older info-beamer pi versions

When using older version you get this error:

CRITICAL ERROR: cannot open serial

The reason is that the serial number of your PI is no longer available in the file /sys/module/bcm2708/parameters/serial: It moved to bcm2709. You can simply fix older info-beamer version using sed:

root@raspberrypi:~/info-beamer-pi# sed -i 's/bcm2708/bcm2709/g' info-beamer 
root@raspberrypi:~/info-beamer-pi# 

There is a new 0.8.2 version available. If you use info-beamer on the new RPI2, you should use this version as it fixes a resource contention problem that only occures now that there's more than one core.

The future

It might be tricky to improve info-beamer so more cores can be used to speed up rendering.

There is a data dependency between a node and its child nodes: The child node rendering is triggered only by calling resource.render_child and the output generated by that call is expected to be available once that call returns. So child nodes cannot be run concurrently to the parent node. This might not be as bad as it sounds since your node code is probably not the limiting factor anyway thanks to the superb performance of the luajit runtime.

It might be possible to improve shared access to the OpenGL context in use. Right now the ownership of the rendering context is temporarily passed to background threads to (for example) upload image data. There are ways to avoid this, so that might be worth exploring.

Most likely your visualizations performance is limited by the GPU fill rate. Even drawing multiple FullHD images during a single frame will be enough to slow your visualization down. There's nothing to gain by using multiple thread in that situation.

It might be possible to squeeze a bit more performance from the new CPU by using the new instructions available. I'd have to test that. But again it probably not going to make a huge difference as CPU is most likely not the limit anyway.

Despite all that I'm really excited about the new PI: It's now possible to do more background work without having to worry about slowing a running visualization down: Download new content or running complex code is now longer a problem.