This release of dyn4j includes some major bug fixes for the SweepLine class and other related convex decomposition classes. It also includes some enhancements to the World.detect methods. See the change detail in the release notes.
A new release of the Sandbox was published for this release for a small bug fix.
The JogAmp community held a Ji Gong freedom talk that reminded people to exercise the 4 freedoms granted by the free software licenses in front of the free java developer room audience. The talk also proposed and showcased technical enhancements for High Availability JVM Technology on All Platforms.
Slides from the Ji Gong talk can be obtained at: https://jogamp.org/doc/fosdem2014/
During the same week JogAmp released version 2.1.4 of its high performance java opengl audio & media processing librarys.
This release includes some new highlights:
* Android OpenCL test apk's. This enable you to compile and test an OpenCL JOCL application on desktop and then deploy on Android without using any OpenCL SDK for the phone, the JOCL binding will locate and bind the OpenCL drivers at runtime.
* Enable use of custom mouse pointers and window icons using the NEWT window and input toolkit.
* Multi window support on the Raspberry Pi including mouse-pointer use directly from console!
Complete list of bugs resolved for this 2.1.4 release can be found at:
This release of dyn4j is a maintenance release to fix a bug in the Vector2.distance(double,double) method. It also had a few methods added to the Body class to get BodyFixture(s) at a given world space point. See the change detail in the release notes.
A new release of the Sandbox was published for this release due to changes in WebStart security and an API change by JOGL.
The #JogAmp #JiGong project will package @OpenJDK + #IcedTea-web to enable good deployment on mobile phone platforms.xerxes // Aug 6, 2013 8:56:07 AM
— Jolla (@JollaHQ) August 6, 2013
JogAmp Ji Gong project announcement
Sven Gothel Aug 04, 2013; 9:45am "
Bug 790 <https://jogamp.org/bugzilla/show_bug.cgi?id=790>
Bug 698 <https://jogamp.org/bugzilla/show_bug.cgi?id=698>
Current Ji Gong Dependency
including the OpenJDK API subset, etc:
1st Milestone - Core JRT for all platforms ..
We are looking for sponsors!
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.
As Xerxes put it: The horse is bound to a chair and is not running ..
Ji Gong <https://en.wikipedia.org/wiki/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.
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.
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.
- 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 http://forum.jogamp.org/Project-Ji-Gong-td4029738.html
JogAmp JOGL, JOCL & JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs. JogAmp is a convenient enabler to give Desktop and Mobile applications access to hardware DSP & GPU units using a modular cross platform API.
This JogAmp JOGL version 2.0.2 release marks the end of the first major JogAmp release cycle that started with the v2.0-rc1 around two and a half years ago, "End of RCs ..". JogAmp JOGL is a modern successor to the no longer maintained JOGL 1.1.1a. The 2.0.2 release added support for OpenGL versions up to 4.3, and OpenGL ES versions 1, 2, and 3.
The JogAmp team hosted one, awesome, party at the JogAmp BOF @ Siggraph 2013!
This years SIGGRAPH JogAmp BOF was dedicated to all the many amazing projects using JogAmp. We did try our best to demo as many projects as possible that we where able to fit into our session. One dude (MIT researcher) put it well, it was like "drinking from a fire-hose"; enjoy the demo flood!
Kudos to Qun who recorded the show! Here is a convenient time line to the many sections and topics covered during the talk:
- LEGACY -
- GAMES -
- UI -
- Art / Science -
- JogAmp -
- Finale -
Slides from the BOF is available at the jogamp.org site: http://jogamp.org/doc/siggraph2013
JogAmp is the home of high performance Java™ libraries for 3D Graphics, Multimedia and Processing.
JOGL, JOCL and JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs.
Running on Android, Linux, Window, OSX, and Solaris across devices using Java.
This 2.0.2-rc12 release include the largest security review in the 10-year history of JOGL
- Security Fixes
- Dynamic Linker Usage / Impl.
- ProcAddressTable field visibility
- Perform SecurityManager checks where required
- Validation of property access
- JAR Manifest tags:
- Use latest Java7 toolchain
- Generating Java 1.6 bytecode
- HTML API doc
Security fixes are marked in red on the above bug tracking page.
JogAmp send out thanks to the FuzzMyApp security researchers for healthy communication that triggered the security review work.
If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place inside the JogAmp forum & mailing-list and the #jogamp IRC channel on irc.freenode.net.
Meet us @
There are a lot of tests on GPU performance, in terms of how many operations per sec (rendering, float arithmetic, etc..), but not a lot on quality and precision. Most would argue that such a benchmark is not very relevant, well that is true in general cases but not all (actually its like having 5k resolution on a 4 inch device; but that is another story). In this post I am discussing the “special” cases where it does matter, focusing on mediump vs highp in fragment programs as well as vertex programs.
Since OpenGL ES specs loosely define the float precision requirements and leaves to the vendors the freedom of implementing it, resulting in having no two devices with same precision. To most applications this is not an issue, but dealing with large CAD data-sets and requiring consistent behavior on all devices such inconsistency becomes an issue especially that this relates directly to the performance.
Testing our application with a Nexus 10 device, that includes the new Mali-T604, encountered a weird bad quality of rendering (second image below). Weird since I had very high hopes for this new device, and the same impl is giving very good quality on its predecessor Mali-400 and on Tegra 3. Searching/experimenting to find hints to this issue, I came across a blog post by Stuart Russell which compares different devices regarding float precision; and a very informative post by Tom Olson describing the float precision on Mali-T604 and why it’s different (which gave the hint/answer to my problem) .
Problem: used to depend on mediump precision on all devices since highp was not available on some of the devices I tested; and since it is not performing well on others even if it says they do. After reading those posts decided to do a similar benchmark but on mediump with the available devices at hand . The shaders are similar to the ones described in the referenced posts, with one modification: color is passed from vertex shader to get an idea on the precision in vertex shaders as well.
Turns out that on Mali-400 MP, Tegra-3, and Adreno 320 the mediump precision is higher than what you expect: (which is 210) and is lower using Mali-T604 especially at the vertex shader. Thus getting a new inconsistency in the data passed from vertex to fragment; which is another reason for the variations shown in the benchmarks.
This inconsistency removes the idea that highp is not really needed on embedded device. And brings another problem on the table, why should we force the highp path in a case that is not needed or in a case where the precision diff is not much (based on the user data). But how can we tell, with no way of querying this precision. If an implementation does declare highp but with insignificant diff with mediump, it would be nice to be able to decide what to choose to enhance performance.
Discussion: The snapshots below show that highp (vertex shader) had no visible effect on Mali-400MP (as well as tegra-2, tegra-3, adreno 320..), but on Mali-T604 it had a major effect (from corrupted scene to a very accurate rendering) . But which implementation is better, cant really tell. But based on specs, both are correct!
Solution: not optimal, but gives correct and “consistent” results
Knowing that my input data is variable (so need for highp or mediump is based on the model), moved to using highp in the cases where it is supported in the fragment language; with the consequence of having un-profitable computations on devices that declare highp but without giving highp.
Finally, since the main variation is found between devices that implement highp in fragment vs those who do not, found the below declaration a compatible way to have “just enough” precision. Thus on mali-400 and tegra-3 we will continue to use mediump as for Mali-T604 it will use highp in the vertex shaders.
//declared in vertex shader
precision mediump float;
precision mediump int;
precision highp float;
precision highp int;
While being asked about JavaFX and whatever other Oracle, Google or
whatever technology, all I can say: I don’t really care – as long it’s free
and complies w/ the 4 freedoms of software.
Lately Oracle even made the proposal JEP 178: Statically-Linked JNI Libraries,
allowing Java applications using JNI within a statically deployed runtime. Read: May work on Apple’s iOS.
IMHO the real issue of being able to deploy ‘Java Tech’ on any platform including mobile/embedded devices is not whether Oracle allows static JNI linkage,
but to allow deploying a custom JRE in the first place.
It is Oracle herself who restricts her patent grant to non embedded devices, hence ‘Java Tech’ does not comply w/ the 4 freedoms of software, see:
IMHO the most advancement Oracle could make to ‘Java Tech’ would be
a general patent and license grant, so you actually would be able to
legally use and deploy your Java’ish builds anywhere and be free
without the hassles and fears of a multimillion dollar battle.
Let it be a build based on OpenJDK, Apache Harmony, DalvikVM .. or whatever
Just my 2 cents ..
[Java is a registered trademark of Oracle, Incl.]
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!
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.
OpenGL ES 3 drivers
Intel have taking the lead and released all their OpenGL ES 3 driver code into Mesa
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.
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
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