zafena development

July 10, 2015

Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt's Mesa3D VC4 driver!

Video of the Processing 3 RGB cube demo running on the Raspberry Pi using Eric Anholt's Mesa3D VC4 OpenGL 2 driver:

Thanks to the free software Mesa3d vc4 driver, the raspberry pi suddenly turned from a mobile opengl es 2 system into a "desktop" opengl 2 system.

Processing 3 is using JogAmp JOGL to tap into OpenGL hardware acceleration on the armv6 Raspberry Pi 1 and armv7 RaspberryPi 2 systems.

Hold on what is going on here, how can I setup the free software vc4 driver on my Raspberry Pi system?

This is a collaboration with Eric Anholt, anholt, and Gottfried Haider, gohai, to get Processing 3 running on the Raspberry Pi.

Eric Anholt has worked about a year to implement a full OpenGL 2 Mesa3D driver for use on the Raspberry Pi by using the Video Core 4, VC4, GPU.

Getting Eric Anholt's Mesa3D VC4 driver running on a Raspberry Pi is easily done thanks to the work by gohai.
gohai started out roughly following Eric's notes here:
And then put together a buildbot in Python, to produce system images for use on the Pi or Pi2.

Kernel, Mesa, XServer packages & dependencies are from git. System image produced using gohai's buildbot

gohai publish daily builds using his bot at:

Myself I have contributed to fix corner-cases in JogAmp JOGL OpenGL initialization to get it all running.

What was the problem using the proprietary OpenGL ES vc4 driver on the Raspberry Pi system?

The OpenGL ES standard do not cover how the native window is initialized.
When you initialize opengl es then you must pass a platform specific EGLNativeWindowType, EGLNativePixmapType and EGLNativeDisplayType depending on the OS you use.

If you read the Khronos header for eglplatform.h you will notice that the EGLNativeWindowType is different for
Windows: typedef HWND EGLNativeWindowType;
Mac: typedef void *EGLNativeWindowType;
Android: typedef struct ANativeWindow* EGLNativeWindowType;
Unix X11: typedef Window EGLNativeWindowType;

Creating an on-screen EGL rendering surface requires you to to use the eglCreateWindowSurface function, which takes a EGLNativeWindowType parameter. On the Raspberry Pi, however this is implemented as a EGL_DISPMANX_WINDOW_T struct, which is defined in eglplatform.h as:

typedef struct {
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;

As you can see RaspberryPi using the properitary binary drivers uses a Broadcom unique native window type that is incompatible with X11.
This is the reason why we cant use the Processing code as is to pass a Java AWT Unix X11 Window to initialize OpenGL ES, EGL will return an error that you have passed an incompatible structure to eglCreateWindowSurface.

When using Eric Anholt's Mesa3D vc4 driver then EGL will expect a Unix X11 Window for its EGLNativeWindowType and this is why processing will work out of the box when Erics Mesa3D vc4 driver in use. Eric's vc4 driver also implements OpenGL 2 that can be initialized using GLX. GLX allows you to run Processing with OpenGL acceleration across remote X11 network connections!

Xerxes Rånby

August 4, 2013

JogAmp Ji Gong project announcement

"Ji Gong shall enable the VM technology across platform and devices."

Sven Gothel Aug 04, 2013; 9:45am "
Bug 790 <>
Bug 698 <>


Current Ji Gong Dependency
including the OpenJDK API subset, etc:


1st Milestone - Core JRT for all platforms ..


Calling for volunteers.

We are looking for sponsors!




OpenJDK and its chair decided not to go mobile?

Bug 698 was written due to the "Fear, uncertainty and doubt" (FUD)
strategy of Oracle of not giving express permission to use OpenJDK
in compliance w/ the 4 freedoms of software (FSF definition).

On the contrary, Oracle gives a patent grant for using OpenJDK for desktop only,
implying mobile use may be prohibited.

This implication is highly likely non-sense, especially in the light of
the latest Oracle vs Google case where Oracle was not able to
substantiate a patent infringement by Google's Dalvik VM.

However .. the current situation lacks of:
- OpenJDK builds for Windows, OSX, Android, ..
- IcedTea-Web builds for Windows, OSX, Android, ..

As Xerxes put it: The horse is bound to a chair and is not running ..

Project Name

Ji Gong <>
"Unlike a traditional Buddhist monk, Daoji did not like following traditional monastic codes. Daoji had a penchant for openly eating meat and drinking wine; his robes were often tattered and dirty from travelling from place to place, and stumbling while intoxicated. However, Daoji was kind hearted and was always ready to lend a helping hand to ordinary people. He would often treat the sick and fight against injustice. The monks, bewildered and fed up with his behavior, expelled Daoji from the monastery. From then on, Daoji roamed the streets and helped people whenever he could."

Hence Daoji does people good while not necessarily conforming to certain arbitrary rules,
while maintaining sanity and being kind hearted.

The character is quite popular in the Asian culture.

Project Spirit


This project shall match the kind direction of it's name giving character,
while also serving w/ JogAmp's goals of being a technology enabler.

Ji Gong shall enable the VM technology across platform and devices.

This project must not necessarily being maintained by the JogAmp community.
On the contrary .. we would prefer this effort to be done from the original authors,
i.e. OpenJDK and IcedTea-Web.

However, until the goals below and this spirit of a free solution is being picked
up, we may continue pushing it forward from here.

Note: Bug 698 sadly wasn't being replied to by neither Oracle nor the OpenJDK team.
Of course, no surprise here, since for Oracle it might be a conflict of interest
due to their 'goals' to market their ARM hotspot proprietary solution
and the OpenJDK team consist mainly of Oracle and RedHat members.
The latter focuses on server solutions and is highly cooperating w/ Oracle.

Project Goal


- Availability of the GPLv2 based OpenJDK runtime environment (JRT/JVM)
- Desktop (Linux, Windows, OSX, ..)
- Mobile (Android, other phones and tablet OS [maybe even iOS])
- VM CPU support:
- Intel/AMD 32bit and 64bit
- ARM based CPUs [Hotspot client/server n/a at time of writing. May need to use JamVM or AvianVM, ..]

- Optional AWT/Swing/etc - maybe added at a later time

- Web Plugin based on IcedTea-Web (JWeb)
- Capable to run w/o AWT using a pluggable windowing subsystem implementation
- Optional AWT/Swing/etc - maybe added at a later time

" Quoted from:

JogAmp forum: Project: Ji Gong

February 14, 2013

OpenGL ES 2 drivers

Excellent post by cnx-software listing all the reverse engineering effort put into bringing opensource ARM GPU drivers to GNU/Linux.
The post links and embeds libv's excellent FOSDEM 2013 reverse engineering ARM GPU driver talk.
The lima and freedreno reverse engineered drivers are both now known to be able to run Quake 3. The lima driver is now actually faster than the closed source ARM Mali driver! - Hey ARM!
We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

-- libv.

OpenGL ES 3 drivers

Intel have taking the lead and released all their OpenGL ES 3 driver code into Mesa - this is how you should work, kudos to Intel.

OpenCL ARM GPU drivers

Android have for a long time refused vendors to ship ARM OpenCL drivers on Google approved Android devices. - Android lead Declined Support for OpenCL
Over night everything changed:
Google ships secret #ARM #MALI T-604 #OpenCL driver in Nexus 10 to accelerate Renderscript.
The OpenCL SDK for ARM Mali is now available! #opencl #gpu @ARMMultimedia
OpenCL drivers for Samsung Exynos 5 board landed here:
Also the Zii labs ZMS line supports CL
Amazon android line is rumored to support CL as well...

So with all these new news surfacing it looks like ARM devices running the new T-604 MALI GPU will have OpenCL drivers especially the Google Nexus 10 tablet that is reported to include the drivers in the stock install!
So this means we now have a good way to hardware accelerate FFT on ARM using OpenCL!
I want to use #OpenCL on #ARM to do fast live music #FFT analysis for better jazz music on the go

JogAmp update

JogAmp have implemented OpenCL bindings on GNU/LInux and packaged .apk for Android feel free to jump in and help with testing on real devices!
The current priority list for JogAmp OpenCL and OpenGL ES 3 integration is found inside the forum:

Cheers and have a great twitter valentine tweet day!
v3 is the new <3

February 8, 2013

This post is about an solution to an old chest nut that still plague ARM Java users on both servers, desktop and mobile. The problem it the impossibility to query the JVM system properties to find out the ABI armel/armhf in use, on ARM systems and possible other ARCH ABI variants as well such as x32, because no information about the ABI is exposed using said system properties. It is mandatory for developers to know the ABI in use at runtime in order to load matching JNI libraries.

About one year ago in 2012 the question got raised inside the #OpenJDK IRC channel but nothing really happened.
Later in 2012 the same question got raised inside the Raspberry Pi community during the move to the new Rasbian armhf system, but nothing really happened except adding more or less creative workarounds to all ARM Java applications and libraries.

The Raspberry Pi community eventually added a Java specific forum and now Oracle engaged in the community and asked for questions: So the question got raised again.
In the end of 2012 Oracle launched their first armhf JVM for the Raspberry Pi but the os.arch namespace was still not fixed, after reporting a workaround for the new JDK 8 EA Oracle took notice.
In the beginning of Jan 2013 Oracle Bob Vandette started an discussion on how to introduce an extended properties namespace that would cover the ABI differences to let applications discover the ABI at runtime.

During the FOSDEM 2013 JogAmp re-raised the question in front of the Oracle audience at 19m23s into the JogAmp talk and the response was "We just discussed that last week". So our reply is "So we can not wait for that". This issue is still causing hairpulling for ARM Java server/desktop/mobile deployments where for example the JVM tries to load armel JNI on the new armhf ARM Linux systems because the system properties set by the new armhf JVM is identical to an armel JVM, loading a library of the wrong ABI do not work.

Q: So what can we do about it?
A: Include an #freejava ELF header parser of course!

#JogAmp #gluegen now implements and use the following ELF header parser:;a=commit;h=371e1dbff6f5f255ab27ed0ab32368abb06eed82 … in order to find out the ABI at runtime without relying on if proper #JVM os.arch & ABI properties are set or not.

Kudos to Sven Gothel for implementing the new ELF header parser using the Gluegen StructAccessor.
Kudos to Andrew Haley, aph, who hatched the idea inside the #OpenJDK IRC channel to scan /proc/self/exe using an elf header parser from within the Java process itself and look for the Tag_ABI_VFP_args ELF header flag, this is what the implemented gluegen solution is based on.

February 6, 2013

I have just returned from FOSDEM where we Julen Gouesse, Sven Gothel and Xerxes Rånby presented a JogAmp freejava love talk with some live demonstrations running hardware accelerated on x86 laptop, android/meego phone/tables and GNU/LInux systems such as the AC100 and RaspberryPi.
Slides, Video and Teaser from the JogAmp FOSDEM freejava love talk are now online:

If you want to design a game then we recommend you to use JogAmp indirect through a game engine library such as libgdx or JMonkeyEngine 3. We have a forum thread inside the JogAmp community where we work on improving engine support for embedded devices such as the Raspberry Pi using said engines. By using a game engine will get you up to speed developing professional games that can be run across all devices and formfactors.
The video and teaser recordings also includes footage of the JMonkeyEngine 3 JOGL 2 backend initialized by Julien Gouesse that we for time reason never managed to show during the strict 40min talk and live demo at FOSDEM.

Inside the FOSDEM talk we ran the open-source libgdx game pax-britannica using the new libgdx JogAmp JOGL 2 port initialized by Julien Gouesse in combination with the new hardfloat fixed CACAO ARM JVM found in the new IcedTea 6 1.12 release on the Raspberry Pi.
we also ran the JogAmp Jake2 port, a port done by Sven Gothel, using the armhf JamVM from IcedTea 7 on the ac100.
Both opensource games of course rocked running using freejava!
The point that we wanted to show is that if you start to use the dedicated love using the media accelerator found in all new devices your java applications rendering will run *equally* fast regardless of the JVM implementation, since the rendering is then performed by the GPU instead of the CPU.

For demonstation purposes: I had to extend the libgdx backend with a custom mouse pointer in order for otherwise touchscreen oriented games such as pax-britannica to work on the Raspberry Pi from console, the reason why this is needed is because there is no highlevel compositing windowmanager running on the RaspPi adding the overlay mousepointer for you like what you are custom to see when running desktop applications using X11. This libgdx RaspberryPi mouse pointer branch allowed me to test all touch oriented libgdx games and demos from console using a mouse input device.

While we know that compilation of custom JVM can be tricky I have prepared a RaspberryPi armhf CACAO that you can use as an drop in replacement into any OpenJDK 6 installation (/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/server/ This was built using the IcedTea 6 1.12 release from inside a Raspbian chroot.
For JamVM simply install the openjdk-7-jdk package and run it using java -jamvm its already built and packaged by the Raspbian team and work great! The new CACAO armhf is found here:

The Raspberry Pi Rasbian armhf distribution have now packaged IcedTea 6 1.12.1 and included it in the distribution, this means that you can test the new armhf CACAO JVM and JamVM JVM by simply installing the openjdk-6-jdk package.

sudo apt-get update
sudo apt-get install openjdk-6-jdk
java -jamvm -version
java -cacao -version

Also a great KUDOS for Qun, our dear camera-woman!

Cheers and enjoy the love!
On behalf of the JogAmp community - Xerxes

August 28, 2012

Last week I stumbled across and dipped my toes into, Avian, a new small and fast JVM that included a JIT for ARM.
Avian have been developed in the open during the last 5 years, I was quite surprised that all this was for me unheard of!
Avian got support to be used in combination with the OpenJDK 7 class library’s:

Build instructions to build Avian on a Raspberry Pi running Raspbian.
sudo apt-get install openjdk-7-jdk libz-dev git

# you may change these two export to match your system
# use i386, x86_64, armhf, armel or ppc here
export ARCH=armhf
# use i386, x86_64, ppc or arm here
export JVM_ARCH=arm

# clone and build avian in combination with one existing OpenJDK 7 jdk image
# It takes about 40 minutes to perform this compilation natively on a Raspberry Pi.
git clone
cd avian
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-${ARCH} make openjdk=/usr/lib/jvm/java-7-openjdk-${ARCH}

# Run the avian test suite to check that your newly built avian pass all expected functionality
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-armhf/ make openjdk=/usr/lib/jvm/java-7-openjdk-armhf/ test

# Install the built avian into OpenJDK 7
sudo mkdir -p /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
sudo cp build/linux-${JVM_ARCH}-openjdk/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
# Add -avian KNOWN to the end of the jvm.cfg file in order to make java -avian work
sudo sh -c "echo '-avian KNOWN' >> /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/jvm.cfg"

# hack for ubuntu and debian to let openjdk find the
sudo ln -s /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/
# the hack/workaround is required if you see the following error when running java -avian -version
# Error: Could not create the Java Virtual Machine.
# Error: A fatal exception has occurred. Program will exit.
# The above hack is not required if you compile your own build of IcedTea or OpenJDK from upstream source directly

# Done now try run it
java -avian -version
# The output to be seen
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1) (7~u3-2.1.1-1+rpi1)
Avian (build null, null)

Avian is heavily tested by its main developers for use running Eclipse SWT applications,
users of Avian have only had working Swing and AWT running during this last month.
expect Java2D to still be a little shaky when using Avian, I expect these Java2D issues to stabilize quickly thanks to the rapid development cycle that takes pace on git hub and thanks to the internal Avian test-suite that gets run after each build.

Avian got some interesting properties:
The JIT is good, it runs at a speed similar to CACAO JIT and the Thumb 2 JIT add-on for Zero.
It is embeddable, you may use Avian to create a small standalone executable that include both the JVM and your application, Avian then uses proguard to cut out and bundle only the needed code from the large OpenJDK class library that is required to run your application, all documented in the avian build documentation. This embeddable feature would possibly allow, free and open-source, OpenJDK applications to be deployed inside walled gardens such as mobile platform application stores, some people even got it to run on webOS. Avian makes Java viable on low footprint embedded systems, a generated standalone executable can be compressed to less than 1Mb!

August 22, 2012

Your CPU is inefficient to render graphics on large displays:

For a long time computer programs and operating systems have been updating the display memory directly using the main CPU. Many high level programming languages was able to draw graphics faster by simply optimizing the internal JIT compiler that allowed the graphics routines to run faster on the CPU. This simple approach was fine when computers got relatively small screens of less than 640x480 pixels the code running on the CPU was then able to update all the 307 200 pixels on the screen using only a couple of Mhz processing time, if you wanted 60 updates per second then your CPU had to update 640*480*60 ≃ 18Million pixels each second, each pixel is made up red, green and blue stored in four bytes on a 32bit display thus 18Million * 4 = 72Million bytes to get updated each second, this was almost still possible to do on a 200Mhz CPU since you then had some time left to do general computations.

When you attached larger pixel density displays then the work load increase, a full HD display at 1980x1080 require that your CPU would need to update 1980*1080*60*4 ≃ 5000Million bytes/second you would then need a 10Ghz CPU to perform this task.. this kind of CPU is impossible to create, it would self-combust, since it require enormous amounts of power because the power consumption and generated heat by the CPU increases exponentially with the increased clock rate.

During the work of porting OpenJDK to run on ARM CPUs a lot of effort went into optimize the JVM to speed up basic computations, this work did also speed up graphics rendering to some degree using a JIT yet we faced a wall. The main bottleneck was limited that we only tried to use the main CPU. I had to find a way to offload graphics tasks from the main CPU to the graphics GPU processor found in the ARM, system on a chip, SoC designs to get good and fluid graphics performance using OpenJDK.

Modern graphics GPUs are designed to render graphics large screens using the least amount of energy:

A modern graphics GPU solves the problem on how to update the large displays by using the least amount of energy by using parallelism at the hardware level, the GPU is made up of several small processor-cores running at a lower clock rate that can receive instructions from the main CPU. The many smaller GPU cores can operate in parallel to quickly update the large screen. The main CPUs task is now changed from updating the graphics memory pixels directly to become a command central with the main purpose to inform the many GPU hardware cores what to do. Luckily the graphics GPU vendors have agreed on a standardised way on how to let applications running on the main CPU to interact and instruct the graphics GPU. The GPU vendors let you access the GPU by using the OpenGL "c" API. OpenGL is accessible by loading a shared library, libGL or libEGL, shipped with your operating-system.

Unfortunately high level languages running on the JVM can not use the system installed libGL or libEGL directly, they require a bridge usually coded in the JNI API to get access to the system OpenGL library. Writing JNI code manually to simply forward all OpenGL library calls would be high maintenance work and error prone.

I did check if there was any existing bindings found buried inside the OpenJDK Java2D classes and yes it did contain an old backend for desktop OpenGL 1 to let Swing and AWT applications run accelerated, unfortunately this backend had not been maintained for many years and was not even enabled by default, instead all Java2D was rendered using the CPU directly, you can enable this OpenGL 1 backend by passing -Dsun.java2d.opengl=True . The existing OpenGL 1 Java2D bindings contained no code to let applications access the most recent OpenGL 2 and OpenGL ES 2 hardware, I had to look elsewhere for a suitable binding to get access to accelerate graphics using the OpenGL ES 2 GPU found inside ARM SoCs.

JogAmp solves the problem on how to get access to your fast GPU to perform rendering from high level languages running on the JVM like Java:

I have worked with the JogAmp community that provide a platform neutral binding that allows languages running on the JVM a low overhead access to the system installed OpenGL library. JogAmp JOGL uses a tool called gluegen to load and probe the system installed libGL and libEGL at runtime and is able to auto-generate the required JNI code and classes to let languages running on the JVM get a low overhead direct access to the OpenGL API!

I have published a small JogAmp JOGL OpenGL ES 2.0 Vertex and Fragment shader introduction, that demonstrates how to access OpenGL 2/ES 2 from Java using JogAmp JOGL at:

The nice thing about this introduction is that the demo source and the compiled java .class will run unmodified on both Desktop OpenGL GL2 systems and Mobile OpenGL ES2 systems.
It uses the JogAmp GL2ES2 GLProfile that use the common subset of OpenGL calls found in both desktop GL2 and mobile ES2. JogAmp will handle all platform specific bits for you like how to open a native drawable surface and let your application focus on rendering using the platform independent OpenGL/ES calls. Note that the demo source-code itself contains no Architecture or OS specific code at all!

Demo break... lets have some fun...

Try the demo on a java enabled Desktop/Mobile running X11/Windows/MeeGo or Mac system:

7z x jogamp-all-platforms.7z
cd jogamp-all-platforms
mkdir -p demos/es2
cd demos/es2
cd ../..
javac -cp jar/jogl-all.jar:jar/gluegen-rt.jar demos/es2/
java -cp jar/jogl-all.jar:jar/gluegen-rt.jar:. demos.es2.RawGL2ES2demo

Raspberry Pi supported!

At Siggraph 2012 i demonstrated for the first time JogAmp JOGL OpenGL ES 2 bindings running on the RaspberryPi, since then all source-code have been committed to the JogAmp JOGL git and been processed through the JogAmp "chuck" auto-builder. Raspberry Pi is supported by the current JogAmp release thus use the same instructions to compile and run as compared to desktop! The Raspberry Pi Broadcom VC IV NEWT driver is included.
I am personally *stunned* by the excellent performance you get on the small Raspberry Pi machine, at 5-watt power consumption, it runs butter-smooth and outclass my desktop Intel Q45/Q43 Chipset system when running at full HD 1980x1080 resolution.

I hope you enjoyed the demo.

Lets talk about the shader programs that got executed inside your graphics GPU:

The only way to create a program that can get run and executed on the GPU is by transmitting shader code to the GPU through the OpenGL 2 API.

The shader program itself is sent as a clear text string to your GPU driver for compilation. When the program is compiled OpenGL hands you a reference to the program in form of a number-ticket that you later on can use to activate the program. You will not be able to actually see the compiled code, what the compiled program looks like is still a secret only known by your GPU vendor.

The opengl API let you define two types of GPU programs, a vertex shader and a fragment shader:

The vertex shader gets executed one time for each vertex:

/* Introducing the OpenGL ES 2 Vertex shader
 * The main loop inside the vertex shader gets executed
 * one time for each vertex.
 *      vertex -> *       uniform data -> mat4 projection = ( 1, 0, 0, 0,
 *      (0,1,0)  / \                                          0, 1, 0, 0,
 *              / . \  <- origo (0,0,0)                       0, 0, 1, 0,
 *             /     \                                        0, 0,-1, 1 );
 *  vertex -> *-------* <- vertex
 *  (-1,-1,0)             (1,-1,0) <- attribute data can be used
 *                        (0, 0,1)    for color, position, normals etc.
 * The vertex shader recive input data in form of
 * "uniform" data that are common to all vertex
 * and
 * "attribute" data that are individual to each vertex.
 * One vertex can have several "attribute" data sources enabled.
 * The vertex shader produce output used by the fragment shader.
 * gl_Position are expected to get set to the final vertex position.
 * You can also send additional user defined
 * "varying" data to the fragment shader.
 * Model Translate, Scale and Rotate are done here by matrix-multiplying a
 * projection matrix against each vertex position.
 * The whole vertex shader program are a String containing GLSL ES language
 * sent to the GPU driver for compilation.
static final String vertexShader =
// For GLSL 1 and 1.1 code i highly recomend to not include a
// GLSL ES language #version line, GLSL ES section 3.4
// Many GPU drivers refuse to compile the shader if #version is different from
// the drivers internal GLSL version.
"#ifdef GL_ES \n" +
"precision mediump float; \n" + // Precision Qualifiers
"precision mediump int; \n" +   // GLSL ES section 4.5.2
"#endif \n" +

"uniform mat4    uniform_Projection; \n" + // Incomming data used by
"attribute vec4  attribute_Position; \n" + // the vertex shader
"attribute vec4  attribute_Color; \n" +    // uniform and attributes

"varying vec4    varying_Color; \n" + // Outgoing varying data
                                      // sent to the fragment shader
"void main(void) \n" +
"{ \n" +
"  varying_Color = attribute_Color; \n" +
"  gl_Position = uniform_Projection * attribute_Position; \n" +
"} ";

The fragment shader gets executed one time for each visible pixel fragment:

/* Introducing the OpenGL ES 2 Fragment shader
 * The main loop of the fragment shader gets executed for each visible
 * pixel fragment on the render buffer.
 *       vertex-> *
 *      (0,1,-1) /f\
 *              /ffF\ <- This fragment F gl_FragCoord get interpolated
 *             /fffff\                   to (0.25,0.25,-1) based on the
 *   vertex-> *fffffff* <-vertex         three vertex gl_Position.
 *  (-1,-1,-1)           (1,-1,-1)
 * All incomming "varying" and gl_FragCoord data to the fragment shader
 * gets interpolated based on the vertex positions.
 * The fragment shader produce and store the final color data output into
 * gl_FragColor.
 * Is up to you to set the final colors and calculate lightning here based on
 * supplied position, color and normal data.
 * The whole fragment shader program are a String containing GLSL ES language
 * sent to the GPU driver for compilation.
static final String fragmentShader =
"#ifdef GL_ES \n" +
"precision mediump float; \n" +
"precision mediump int; \n" +
"#endif \n" +

"varying   vec4    varying_Color; \n" + //incomming varying data to the
                                        //frament shader
                                        //sent from the vertex shader
"void main (void) \n" +
"{ \n" +
"  gl_FragColor = varying_Color; \n" +
"} ";

Use the source!
When you first look at the source code you might find the many lines needed to render a single triangle scary.
Take a break and instead focus on the display function that gets executed about 60times/s here notice that the CPU only have to perform a handful of 4x4 matrix multiplications and then call about 15 function calls to pass all data information to the vertex and fragment shader programs inside the GPU. The GPU then by itself performing all rendering to the screen. This small amount of preparation done by the CPU each frame can easily be performed by the most simple JVM interpreter. The main bottleneck is gone we have successfully offloaded all the time consuming graphics rendering from the CPU to the GPU and as a bonus we find that we got a lot of free idle CPU time to perform general application logic computations on the JVM.

Edit: For game programming we recommend you to use JogAmp indirect through a game engine library such as libgdx or jMonkeyEngine3. We have a forum thread inside the JogAmp community where we work on improving engine support for Raspberry Pi using said engines. By using a game engine will get you up to speed developing professional games that is utilizing the hardware acceleration across devices!

Edit2: New JogAmp video/teaser footage is now online for the FOSDEM 2013 talk and the Siggraph 2012 BOF to get a better idea on what is possible to using JogAmp in combination with engines across devices. You may want to read the post that include background information on the FOSDEM 2013 demo setup.

I hope this introduction have been a delight to read, cheers and have a great day!

July 30, 2012

Robert Lougher have updated JamVM to work on the new Raspberry PI armhf "Raspbian" image, thank you Robert! You can compile and test this latest JamVM version from source on a Raspberry PI by running the following lines inside a terminal:

sudo apt-get install openjdk-6-jdk git libtool autoconf automake

git clone git:// jamvm

cd jamvm

./ --with-java-runtime-library=openjdk6


mkdir /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm

sudo cp src/.libs/ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm/

sudo sed -i 's#-jamvm ERROR#-jamvm KNOWN#' /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jvm.cfg

java -jamvm -version

java version "1.6.0_24"OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2+rpi1)

JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

I have update IcedTea6 1.12 and IcedTea7 2.3 release branches to include this updated version of JamVM. Distributions like Debian/Fedora/Ubuntu/Arch and Raspbian will get this new work when they update IcedTea to include the next IcedTea release or security update. This is the first JamVM + OpenJDK update in 2012, this update also include support for JamVM to run the QT-Jambi GUI toolkit.

February 27, 2012

Today JogAmp added a workaround to deal with GPU drivers that reports a bogus 0Hz screen refresh rate. With this fix in place hardware acceleration are working out of the box on Nokia N9 MeeGo phones in combination with the Nokia compiled Imaginative Technologies SGX 530 GPU drivers!

If you have OpenJDK installed on any ARMv7 board with a proper OpenGL-ES libEGL and libGLES driver setup then you can try running this for yourself by using my prebuilt jogamp-armv7 jars.


tar zxvf jogamp-armv7.tar.gz

cd jogamp

sh ./

Source and build instructions are available.

JogAmp JOGL OpenGL-ES Driver compatiblity matrix

I am tracking ARMv7 libEGL/libGLES* GPU drivers compatiblity with JogAmp here:

Chuck Norris force you to use the produced jars from the JogAmp "Chuck Norris" build-bot! uses gluegen build 510

Assemble a ARMv7 jogamp testfolder using the JogAmp daily build:



7z x gluegen-2.0-b510-20120225-linux-armv7.7z

7z x jogl-2.0-b684-20120227-linux-armv7.7z

mkdir -p jogamp/jar
cp -r jogl*/etc jogamp/etc/
cp gluegen*/jar/*.jar jogamp/jar
cp gluegen*/lib/* jogamp/jar
cp jogl*/jar/*.jar jogamp/jar
cp jogl*/lib/lib* jogamp/jar
cp /usr/share/java/hamcrest-core.jar jogamp/
cp /usr/share/java/junit4.jar jogamp/

cd jogamp

java -cp jar/gluegen.jar:jar/jogl.all-mobile.jar:jar/jogl.test.jar:hamcrest-core.jar:junit4.jar com/jogamp/opengl/test/junit/jogl/demos/es2/newt/TestGearsES2NEWT -time 40000


February 25, 2012

I have created a Twitter stream where I track my current progress on getting desktop OpenJDK applications running faster on ARM by taking advantage of the OpenGL ES, possibly in combination with the lima driver, and OpenVG hardware acceleration.

OpenJDK  currently fallback to used CPU bound software rendering to draw most of Java2D and 3D application on ARM.

I decided to look into it and noticed that OpenJDK internally currently only support fast hardware acceleration on GNU/Linux systems by using the standard libGL OpenGL library, this libGL library do not support the latest ARM system on a chip GPU designs instead it allways fallback to use the uttelry slow Mesa software rasterizer. In order to get things fast OpenJDK need to take controll of the ARM GPU's using the libEGL and libGLES* OpenGL ES library drivers.

You can get OpenJDK running 2x faster today by simply setting:


This will enable the xrender pipeline made by Clemens, its compiled in most OpenJDK builds and are simply waiting for you to switch it on to test it, its not as fast as the libEGL drivers but its faster than the pure software rendered X11 pipeline. :)

I expect to get OpenJDK running butter smooth when proper hardware acceleration using JogAmp or LWJGL are in place, both of these API have recently added OpenGL ES support in the latest releases. A promising candidate to make it happen are to combine the JogAmp JOGL OpenGL ES bindings with Brandon Borkholder's GLG2D.!/xranby -Tweeets for you!

Older Posts »

Powered by WordPress