Raspberry PI 2 – first impressions

It was some time since I used my original Rasperry PI, as it had been gathering dust for a number of reasons.  The main reason was one of performance, as much as anyone might love the PI they cannot claim that at 700mhz browsing the internet on a PI is anything more that a turgid experience.

So you can understand when reading of a claimed six fold improvement in performance my interest was defiantly piqued…

I’ll start off with a round up of the good! basically the performance is defiantly there – to the extent that browsing the internet is actually practical.  The improved architecture (ARMv6 v’s ARMv7) and the increase clock speed to 1Ghz definitely make a difference, what makes less of a difference is the fact it’s a quad core.  While for heavy weight applications (multi core compiling, rendering etc) it will have quite an impact, for general desktop use, you are unlikely to be troubling multiple cores (at the same time)

Obviously this extra power comes at a price, namely power (the other sort!) you will defiantly require a decent power supply – (a good quality 2amp wall wart is indicated) – this meant for me that even with the power plugged into my lapdock, it just didn’t quite cut it.  This leads on to a useful feature – if the PI doesn’t have sufficient power you will see a small 4 colour icon in the top right of the screen.  This extra power requirement may well catch a number of people out but then there is always the option to underclock…

The thing that disappointed me most is the seeming lack of low level (open source) progress, for example the implementation of EGL / GLES only really allows for fullscreen rendering in X11, however from my experimentation it should be quite possible to have a small (hardware) overlay window on top and moving around with a blank X11 window, all this with no copying during buffer swaps.  While I was tempted to have a go at an X11 version of EGL / GLES the thing really putting me off is the lack of documentation for broardcoms API.  Sure you have *some* of the source code, and even a datasheet, but without proper docs its hard to guess how you’re supposed to do something new with the API (as opposed to following boiler plate examples)

The upshot of all this is that although I should be able to take a program I’ve written on my laptop targeting GLES2.0,  recompile it on the PI and it just work, alas this is not possible – you have to port from Linux to Linux and add platform specific code… (not a great thing to be encouraging people in education to be doing…)

So its a mixed bag, I’d really like to see the PI become an end to end open source solution (with work on reverse engineering the firmware) but Broadcoms marketing stunt about opening up the PI was somewhat disingenuous – being basically a bunch of RPC glue and stubs to call GPU binary blobs even the shader compiler is a binary blob!

So hardware performance – could do better but a great improvement

Open and cross platform compliant…. errrr NOT (still!)


Leave a Reply

Your email address will not be published.