Shader Performance


I tried running a couple of shaders and was disappointed that the FPS is pretty low even for fairly simple shaders.

I guess this is a limitation of the hardware - does the Pi even have a GPU? Any tips for improving performance in the shader or in the hardware?


  • Felix

BTW I’m on a Pi 3

Hey Felix —

We’ve actually been pleasantly surprised at how smoothly most of the shaders we’ve tried run, but I don’t think we’ve tried anything super complex. The Pi certainly has a GPU, which is what allows shaders to work on it… on the Pi 3, it’s a Broadcom VideoCore IV.

I’m not an expert in shaders by any means — we can check with Patricio Gonzalez Vivo (who created The Book of Shaders).

Out of curiosity, do you have a link to the shader you’re trying to run?

Hi Felix,

The Raspberry Pi 3 GPU is relatively week. Even if the drivers are not highly optimised, there is just a limit to what you can do.

For the same price of a Raspberry Pi 3 you can get a Hardkernel Odroid computer with ARM Mali GPU.

The XU4 has a fan, is a bit noisy. But even the C2 would give you much better graphics performance.

This video shows some WebGL demos running on the XU4, this should give you an idea of what’s possible with a computer selling for $74.00. You can run Android, Ubuntu, and Tizen on the Odroid XU4.

So maybe running openframe on an Odroid would give you the needed performance. I can do a test, if you are interested. Just point me to some example code which you want to run.

  • Raju

Thanks for the response guys. It totally makes sense that the Pi would have limited performance. I will look into the Ordroid as an alternative.

Regarding specific shaders to test against, I just shared a couple I built in the OF stream (Chrome Grill and Gilmore Leaves by Felix Turner). Sorry not sure how to link specifically to them? Both are fairly simple and are chugging on the PI3. But any non-trivial shader on would be worth testing against. For example:


Found the shader URLs: and

I recently picked up an Odroid C2, and have a few older (X3 and C1) models around, but haven’t yet had a chance to get Openframe running on them. There’s no reason why it can’t work on those devices, though the extensions will need to be updated. I’d love to hear reports if anyone tries it!

Did a test run of installing openframe on Odroid XU4 with Ubuntu 15.10 yesterday. Doesn’t work out of the box, since the build is relying on Broadcom GPU for RPI.

Building glslviewer standalone:

odroid@odroidxu4:~/openframe/glslViewer$ make


g++ -Wall -O3 -std=c++0x -fpermissive -DGLM_FORCE_CXX98 -DPLATFORM_RPI -Isrc/ -Iinclude/ -I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -g -c src/main.cpp -o src/main.o -Wno-deprecated-declarations

In file included from src/app.h:28:0,

             from src/main.cpp:32:

src/gl/gl.h:13:22: fatal error: bcm_host.h: No such file or directory

compilation terminated.

Makefile:53: recipe for target ‘src/main.o’ failed

make: *** [src/main.o] Error 1

Running the glsviewer version (binary) shipping with openframe, the missing libbcm is naturally causing problems as well:

odroid@odroidxu4:~$ glslViewer

glslViewer: error while loading shared libraries: cannot open shared object file: No such file or directory

Same problem has been reported when people tried to compile openframeworks on the Odroid:

They use a switch to check for Raspberry PI in the header files, that might work for openframe:


#include “bcm_host.h”


Another error was the missing omxplayer package for the full openframe build. See the build log below (Odroid XU5 / Ubuntu 15.10):

odroid@odroidxu4:~/openframe$ bash -c “$(curl”

% Total % Received % Xferd Average Speed Time Time Time Current

                             Dload  Upload   Total   Spent    Left  Speed

100 3558 100 3558 0 0 9725 0 --:–:-- --:–:-- --:–:-- 9747

% Total % Received % Xferd Average Speed Time Time Time Current

                             Dload  Upload   Total   Spent    Left  Speed

100 7766 100 7766 0 0 7389 0 0:00:01 0:00:01 --:–:-- 7396

=> nvm is already installed in /home/odroid/.nvm, trying to update using git


=> Source string already in /home/odroid/.bashrc

=> You currently have modules installed globally with npm. These will no

=> longer be linked to the active version of Node when you install a new node

=> with nvm; and they may (depending on how you construct your $PATH)

=> override the binaries of modules installed with nvm:


├── openframe@0.3.6

├── openframe-glslviewer@0.2.2

├── openframe-image@0.2.0

├── openframe-video@0.2.1

└── openframe-website@0.2.5

=> If you wish to uninstall them at a later point (or re-install them under your

=> nvm Nodes), you can remove them from the system Node as follows:

 $ nvm use system

 $ npm uninstall -g a_module

=> Close and reopen your terminal to start using nvm

source nvm

install node

v4.3.2 is already installed.

Now using node v4.3.2 (npm v2.14.12)

[sudo] password for odroid:

install server utils

Reading package lists… Done

Building dependency tree

Reading state information… Done

x11-xserver-utils is already the newest version.

0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

install openframe

Cool, thanks very much for this report! As expected, looks like there will be some work to do to get things running on the Odroid.

We can try updating the glslViewer build to include bcm_host.h only on the Pi like openFrameworks does… not knowing much about this, I’m not sure what effect that might have? Any idea?

For the video extension, not sure if we’ll be able to build omxplayer for Odroid… maybe we can use ffmpeg/ffplay instead? Will look into that.

Modifying the Makefile is not going to solve the problem, I tested that. Currently there are three different platforms supported: Linux, Mac, and RPI. For Linux & Mac OpenGL calls are used, for RPI OpenGL ES. But that code is RPI specific:

But the OpenGL ES code is RPI specific, so we have to create an Odroid version of that code. I’ll see if I can get something up and running on Odroid over the weekend.

  • Raju

Hi Felix, I’m a big fun of your work.

I saw with excitement that you push some shaders using the editor : )

The RPi’s GPU is not really powerful. Actually it doesn’t do real multi threat… @_vade was telling me the other day that it use a tiling system…

Any way… my advise is to avoid for loops… and logic brunches with if statemes… Also matrix calculations, sqrt, pow and others like atan could be surprisingly expensive.

The size of your screen also matters… both of your shaders runs beautifully in smaller screens.

I know coding shaders for the PI is a pain but also is an interesting teacher : /



Hi Patricio,
Thanks for sharing that info with us, will have to test with RPI 2 to
compare performance.

Have you ever tried running glslviewer on a NVidia Jetson TK1 board? I
tried to compile, but the make file needs to be tweaked (ARM CPU, but
should use the desktop build). Jetson supports OpenGL 4.x and OpenGL ES
3.1, has 192 cores - but still low power consumption.

The Tegra K1 SOC in Jetson TK1 is aimed at tablets and thus typically uses
between 0.6W to 3W of power during normal use and rarely uses more than 4W,
but is able to reach 15W if you manage to push the CPU, GPU, camera ISP's
and codec hardware to their limits.

So for full HD displays with some GPU intensive shaders running, that would
be a really nice board. Was sold at $192 last year.

Cheers, Raju

thanks Patricio - love your work on Book of Shaders + Openframe!

Yeah I naively assumed if it ran well on shadertoy it would run on the RPi :slight_smile: Will need to think about working within the RPi’s limitations…

Sorry to resurrect something so old, but I’m thinking about building an OF. My personal use case would be for things like shaders and Processing sketches rather than images/videos.
Based on @patricio comment “The size of your screen also matters” -

@patricio - What size seems good?

@felix - What resolution is the monitor you’re trying to use?