zafena development

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.
http://www.cnx-software.com/2013/02/14/open-arm-gpu-drivers-fosdem-2013-video-and-call-to-arm-management/
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!

http://libv.livejournal.com/24092.html - 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
http://linux.slashdot.org/story/13/02/13/1756208/intel-supports-opengl-es-30-on-linux-before-windows
http://www.phoronix.com/scan.php?page=news_item&px=MTMwMDg

http://cgit.freedesktop.org/mesa/mesa/log/?h=gles3 - 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.
http://code.google.com/p/android/issues/detail?id=36361 - 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.
http://www.youtube.com/watch?v=GrqKJehawr8
http://beyond3d.com/showthread.php?t=63071
The OpenCL SDK for ARM Mali is now available! http://bit.ly/YOS1YA #opencl #gpu @ARMMultimedia
OpenCL drivers for Samsung Exynos 5 board landed here: http://streamcomputing.eu/knowledge/sdks/samsung-exynos-5-board/
Also the Zii labs ZMS line supports CL http://codedivine.org/2013/02/01/renderscript-from-the-perspective-of-an-openclcudac-amp-programmer/
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
http://www.jazzperiments.com/jazzperiments.html

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: http://forum.jogamp.org/JInput-Delivery-tp4028209p4028210.html

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

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. http://download.java.net/jdk8/docs/api/java/lang/System.html#getProperties%28%29 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 http://icedtea.classpath.org/wiki/New_os.arch_namespace_Architecture 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, http://www.raspberrypi.org/phpBB3/viewtopic.php?p=201105 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.
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=236983#p236983
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 http://www.raspberrypi.org/phpBB3/viewtopic.php?p=238135#p238135 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.
http://mail.openjdk.java.net/pipermail/porters-dev/2013-January/000426.html

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: http://jogamp.org/git/?p=gluegen.git;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:
http://jogamp.org/doc/fosdem2013/

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.
http://forum.jogamp.org/JOGL-2-0-OpenGL-OpenGL-ES-backend-for-LibGDX-tp4027689.html
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 libjvm.so 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/libjvm.so) This libjvm.so 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 libjvm.so is found here: http://labb.zafena.se/cacao/armhf-armv6/libjvm.so

Edit:
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

Powered by WordPress