I have posted a small JogAmp JOGL OpenGL ES 2.0 Vertex and Fragment shader introduction at:
https://github.com/xranby/jogl/blob/master/src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RawGL2ES2demo.java#L54

The nice thing about this introduction are that it will run unmodified on both Desktop OpenGL GL2 systems and Mobile OpenGL ES2 systems.
It uses the GL2ES2 GLProfile that use the common subset of OpenGL calls found in both desktop GL2 and mobile ES2.

wget http://jogamp.org/deployment/jogamp-test/archive/jogamp-all-platforms.7z
7z x jogamp-all-platforms.7z
cd jogamp-all-platforms
wget https://raw.github.com/xranby/jogl/master/src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RawGL2ES2demo.java
javac -cp jar/jogl.all.jar:jar/gluegen-rt.jar RawGL2ES2demo.java
java -cp jar/jogl.all.jar:jar/gluegen-rt.jar:. RawGL2ES2demo

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.

wget http://labb.zafena.se/jogamp/armv7/jogamp-armv7.tar.gz

tar zxvf jogamp-armv7.tar.gz

cd jogamp

sh ./run-desktop.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:

http://jogamp.org/wiki/index.php/OpenGL_ES_Driver_compatibility_matrix

Chuck Norris force you to use the produced jars from the JogAmp “Chuck Norris” build-bot!

https://jogamp.org/chuck/job/jogl/684/

http://jogamp.org/deployment/autobuilds/master/jogl-b684-2012-02-27_11-04-43/
http://jogamp.org/deployment/autobuilds/master/jogl-b684-2012-02-27_11-04-43/artifact.properties uses gluegen build 510
http://jogamp.org/deployment/autobuilds/master/gluegen-b510-2012-02-25_20-44-27/

Assemble a ARMv7 jogamp testfolder using the JogAmp daily build:

wget http://jogamp.org/deployment/autobuilds/master/gluegen-b510-2012-02-25_20-44-27/gluegen-2.0-b510-20120225-linux-armv7.7z

wget http://jogamp.org/deployment/autobuilds/master/jogl-b684-2012-02-27_11-04-43/jogl-2.0-b684-20120227-linux-armv7.7z

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

Enjoy!

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:

_JAVA_OPTIONS=”-Dsun.java2d.xrender=true”

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.

https://twitter.com/#!/xranby -Tweeets for you!

Jim Connors at Oracle posed a interesting valentines gift, a compare of the latest open-source OpenJDK ARM JVM inside IcedTea6, 1.12pre, HEAD against their closed source Hotspot c1 and c2 implementations.

https://blogs.oracle.com/jtc/entry/comparing_jvms_on_arm_linux

The Oracle blog antispam system in use...

I would have liked to comment directly on your blog but your spam system kept me at bay so i posed my reply to you here instead

The OpenJDK Zero *mixed-mode* JVM used in Jims compare includes the now re-maintained ARM Thumb2 JIT and assembler interpreter port that got re-introduced in the IcedTea6-1.11 release.
Many of the OpenJDK JVM like CACAO and JamVM are by design tuned for embedded and client use and thus show strength in both low memory overhead and fast startup time.

When testing JVM performance on ARM its important to remember that the default optimization settings used by the compilers to build the JVM do matter.

The Debian 6.0.4 squeeze “armel” distribution use ARMv4t optimization by default. This low optimization level enable the Debian built packages run on as many kind of different ARM broads and CPU’s as possible. The trade-off are that you basically disable all VFP, floating point, optimizations and make synchronization code slower by forcing the JVM to call the Linux kernel helper instead of using faster ARMv7 atomic instructions directly.

To give OpenJDK JVM a better match i would suggest re-running the benchmark using OpenJDK built on top of Debian wheezy “armhf”, Ubuntu Precise “armhf” or Fedora F15 that by default optimize for the ARMv7 thumb2 instruction-set and make use of the VFP unit inside the CPU, also the “armhf” ABI allows better argument passing between library functions inside the CPU VFP registers. Two OpenJDK JVM, JamVM and Zero,  are already updated to support the new “armhf” hardfloat ABI.

You could also choose to run this benchmark using OpenJDK JVMs built using the Ubuntu Precise “armel” tool-chains that still use the legacy soft-float ABI while still adding ARMv7 Thumb2 and VFP optimizations. All OpenJDK JVM tested in this compare would run better by simply using a higher optimization level during the build.

All in all thank you Jim to give an introduction to the ARM OpenJDK porting effort, I look forward to the follow up article where all the JVM makers have picked their favourite GCC/Clang/Foo compiler options and suitable matching compile flags. One idea are to create a OpenJDK binary release with a custom OpenJDK installer that would ease testing of tuned OpenJDK JVM implementations.

Cheers, Xerxes

The brand new Tizen SDK got released

Tizen are a new mobile platform with the aim to thrive in a new ecosystem made up of HTML5 and js based applications.

The Tizen SDK includes the Eclipse IDE and an emulator themed after Samsungs new atom-phone reference design. The emulator come pre-installed with a functional Tizen phone system and some sample applications.

Booting up Tizen

The emulator can get started from the Tizen Emulator Manager. I can then connecting to it by running

sdb shell

Under the hood we can find a small Debian GNU/Linux root filsystem, an Xorg server, pulseaudio and many other nice system services just like on regular Linux desktop. This are good because it will enable us to quickly add some new software stacks to Tizen!

OpenJDK on Tizen

After a quick sdb push i had uploaded a pre-built OpenJDK-6 image running the LLVM 3.0 based Shark VM into Tizen and behold: oneslime on Tizen

Thank you Linux foundation for pushing GNU/Linux into mobile phones!

Summary: OpenJDK work fine on Tizen and the Tizen SDK work fine using OpenJDK!

I have been following the CACAO JVM development on ARM since 2008, back then CACAO was one of the first alternative JVM, to be used instead of Hotspot in combination with the OpenJDK 6 class libraries.

CACAO history dates back to 1997-1998 when CACAO was one of the first JIT compiler to be used instead of SUN’s Java JVM interpreter.

Today CACAO are being used in combination with OpenJDK 6 on architectures like ARM, MIPS and PPC where Oracle have not yet released code for a GPL licensed Hotspot JIT. CACAO are popular, see the Debian OpenJDK-6 popularity contest chart where up to 80% of all the Debian OpenJDK 6 JVM users have picked CACAO to be installed. This trend kept on since the beginning of 2009 up to the summer of 2011.

Carpe diem CACAO JVM!

During the summer of 2011 Oracle released OpenJDK 7 and CACAO users started to abandon the JVM in favour for JamVM, the reason “why?” are that CACAO depends on the HPI API that have been removed from the OpenJDK 7 code base. This means that CACAO currently only work in combination with the “classic” OpenJDK 6. The second black cloud for CACAO JVM on ARM was that all major ARM Linux distributions started to move from “armel” towards the new “armhf” ABI something CACAO do not support. JamVM here provided the ARM Linux distributions and users with a stable and future proof alternative.

If we for a moment forget about the future and focus on today CACAO are in great shape when built from CACAO hg HEAD.

• CACAO are FAST, http://openjdk.gudinna.com/benchmarks/
• CACAO are stable, thanks to Stefan Ring who have been diligent on fixing bugs found in the CACAO JIT codegen.
• CACAO are fresh, the current CACAO hg HEAD contains the rewritten, “still unreleased” C++ version of CACAO its a totally different JVM compared to the last C based release of CACAO 0.99.4.

If you want to experience the CACAO JVM in its finest the do run the latest development version of CACAO in combination with OpenJDK 6, built using the current IcedTea6 head. Run it on ARM “armel”, PPC or MIPS and experience a fast responsive JVM burning brighter than ever before!

LLVM3.0 target feature matrix : http://llvm.org/docs/CodeGenerator.html#targetfeatures

LLVM 3.0 have been released

LLVM includes the JIT that can be used to speed up OpenJDK on all platforms that currently only have support by the platform independent Zero C++ hotspot port.

The JIT in LLVM have been redesigned from the ground up to use the same code path ways as used by the static compilation in LLVM by using the new MCJIT that in turn are based on the new direct Machine Code emission back-end. LLVM will over time drop support for the old “classic” jello-JIT.

OpenJDK Shark + LLVM 3.0 patches exist on zero-dev

I have posted some LLVM 3.0 patches to zero-dev that allows OpenJDK Shark to be built using this new MCJIT. Grab them all at: http://mail.openjdk.java.net/pipermail/zero-dev/2011-August/thread.html

Builds and testers are needed for MIPS, PPC and ARM

Shark are known to work stable on X86 hardware where all parts of LLVM have great community support. For all other architectures please check out the LLVM Target Feature Matrix.

According to this Target Feature Matrix table, MIPS JIT support are now GREEN! MIPS devs should try the OpenJDK + Shark + LLVM 3.0 combination, it could turn out to be really good. If you have a spare MIPS machine that are online 24/7 do consider adding it to the LLVM and IcedTea buildbot network!

For ARM the MACH-o JIT backend are supposed to be working, testers of OpenJDK + Shark + LLVM 3.0 on darwin based platforms like the iPhone and iPad please step forward, this combination looks to be working, at least on paper.

All ARM Linux users have to wait until the ELF MCJIT are stable before we can expect to run Shark using LLVM 3.0 and later.

PPC testers are also needed, LLVM support for PPC have been 90% good in the past.. it could be all broken or all working, no-one really know at least the LLVM darwin PPC buildbot shows some green lights but we currently do not have any IcedTea PPC buildbots to check if Shark + PPC work at all.

Android window running on top of a unmodified OpenJDK 6b22 using IcedRobot.

While I was reviewing Guillaume’s graphics stack patches for IcedRobot this window poped up on my desktop. Im amazed, IcedRobot are able to run Android Activity’s on top of a GNU/Linux desktop using a unmodified OpenJDK 6b22. Android app developers prepare yourself to start see your apps migrate into GNU/Linux desktops!

If you are new to IcedRobot then check out Mario’s nice statement on the current overall progress of the project.

I have for a long time never looked at using JavaScript in any of my projects because of its untyped nature. But now all have changed.
Thanks to the Processing.js project it are now possible to write complex JavaScript code using all familiar typed “Java” syntax used by the http://processing.org language.

You can now take existing Processing “Java” sketches and convert them into into plain JavaScript code without actually changing a line of the original processing .pde file!
WOW!, This are the coolest thing I have seen in a long time since it enables me to start create all kinds of nice HTML5 doodles using the same syntax used in regular “Java” programs and then run them on any HTML5 capable device without actually having to install a “Java” browser plugin!

Have fun and jump instantly into some coding action at: http://sketchpad.cc – a online Processing.js IDE!

If you want to get inspired on how to create processing sketches then check out this all awesome OpenProcessing sketch archive at http://openprocessing.org.

Here running reach3 from the http://processingjs.org/learning/topic archive.

Thanks a lot to John Resig for making this work. (Get the source! MIT licensed)

Thanks to the IcedRobot project, it are now possible to run Android .dex files on top of any GNU/Linux system using OpenJDK and JamVM!
xranby@babbage:/wd/daneel$ java -jamvm -showversion -cp target/daneel-0.0.1-SNAPSHOT-jar-with-dependencies.jar \
-Djava.system.class.loader=org.icedrobot.daneel.loader.DaneelClassLoader -Ddaneel.class.path=src/test/java/resources/HelloDroid.dex \
org.icedrobot.test.HelloDroid
java version “1.6.0_18″
OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2+squeeze1)
JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

Trying to find class ‘org.icedrobot.test.HelloDroid’ …
Hello Android!

xranby@babbage:/wd/daneel$ uname -a
Linux babbage 2.6.28-11-imx51 #42 Tue Jun 23 11:27:23 BST 2009 armv7l GNU/Linux

(more…)