Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  LWJGL3 and Android Redux  (Read 15569 times)
0 Members and 1 Guest are viewing this topic.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Posted 2016-12-20 19:08:25 »

Hi @spasi. I'd like to continue the discussion from the previous LWJGL3 & Android thread which is locked now.

As more or less expected Google is declining to make a Vulkan Java binding for Android. Even giving what I think is a weak answer:
There are no plans to do a "pure" wrapping of Vulkan in Java. Vulkan would make a poor Java-language graphics API, and the overhead of JNI would mean losing many of the benefits that it's supposed to provide.

I doth protested, but it's not likely Google's position will move. There are no more Java champions on the graphics side willing to take a stand within the Android team. This matches the sentiment I got from a light probing earlier this year. Hopefully they absolutely don't create some new API on top of Vulkan as mentioned in a follow up to the above quote.

Anyway... I am 100% down to collaborate and help create and maintain a LWJGL3+ port for Android. Don't worry about the API level needing to be high. It might even have to be API level 24/25; Android N and that's fine. I do have some complex direct GL/ES code with the video engine and that's even kind of neat because it would really be pushing things to get LWJGL3 setup to drive it (if possible). We can't let this go unused!  Roll Eyes  I'd be fine switching to LWJGL and doing an Android N release of the video engine if it could actually work; would have lot's of data then on new device compatibility! Too bad I'll have to stick to GL/ES, but it'd be interesting. I'd be glad to get some GL/ES and Vulkan demo code out there. I already have an Android GL/ES starter available which I'd rewrite for LWJGL3 via GL/ES in addition to a potential Vulkan version. In this effort I actually provide improved facilitating framework code where the Android API is long in the tooth.

I've got tons of devices with each generation of GPU and would be glad to test, refine, and work on any necessary optimizations.

It seems like Android N / API 25 w/ the switch to OpenJDK would be the first to get stable w/ GL/ES and Vulkan paths. I know there is a bit of sun.misc.Unsafe usage and / or some JNI fallback code for JVM optimization. Even if things started with Android N that's great as there is a huge hole opening up on Android for performance graphics and LWJGL and can fill it.

So since I only have a cursory overview of LWJGL3 from poking through the source code I'd be curious to hear what you think will be the pain points? How are you handling JDK9 removal of sun.misc.Unsafe?

I think the first thing is to evaluate what's potentially necessary / missing for an easier port. Maybe the Android team would be slightly helpful if there is something missing that could potentially be exposed in the future if no workarounds exist. Just kind of thinking out loud at this point... I'm down to make it happen though.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #1 - Posted 2016-12-20 20:38:28 »

Hey, quick reply (I had a minor operation today and am in a bit of pain atm):

I still haven't done any work on ARM/Android, but I have new information to share. @KaiHH has been working hard to make JOML perform nicely on Android (it's being used in Samsung's GearVR SDK) and I asked him to do a bit of testing for me. Turns out that, indeed, starting with Android N and the OpenJDK-based SDK, the current LWJGL design might be viable. Unsafe seems to be a lot faster at least.

I've got tons of devices with each generation of GPU and would be glad to test, refine, and work on any necessary optimizations.

That's great, will be very helpful.

So since I only have a cursory overview of LWJGL3 from poking through the source code I'd be curious to hear what you think will be the pain points? How are you handling JDK9 removal of sun.misc.Unsafe?

LWJGL 3 depends on Unsafe and escape analysis for extreme performance. Workarounds may be possible, but at the expense of clean code.

JDK 9 does not remove sun.misc.Unsafe and it's available to all modules (there's a new, much more powerful, Unsafe in 9 that is available only inside the JDK). As of this commit LWJGL 3 also works on JDK 9 b148+, which introduced a lot of significant changes to the module system.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #2 - Posted 2016-12-20 21:23:26 »

Get well!

I do look forward in how this can proceed and to start can probably squeeze out ~10 hours a week to help test, but certainly would be glad to get up to speed on the LWJGL architecture / build process in time. If there was a time to get this going though it sure does seem like now!  Grin

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2016-12-20 23:38:53 »

I will support you as much as I can, but my time and skills are a bit limited in this area. I can however provide pretty big test programs once my Vulkan abstraction makes some more progress.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 486



« Reply #4 - Posted 2016-12-23 11:35:25 »

As of this commit LWJGL 3 also works on JDK 9 b148+, which introduced a lot of significant changes to the module system.
Thanks to the JDK-9 module workaround by @Spasi, JOML now also runs Unsafe-accelerated under Java 1.9 (as well as the already supported Java 1.4 through 1.8 ) on Windows, Linux and OS X.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #5 - Posted 2017-01-19 13:52:14 »

Hi @Spasi.. I hope you are feeling better!

Just dropping a note that I'll be attending GDC for the GL / Vulkan sessions and tutorial day. There will be a talk on native usage of Vulkan / Android, but I'd be glad to submit a lightning talk (5 min) and perhaps have the chance to drop the details on LWJGL support on Android & icing on the cake if Vulkan is supported. Regardless if the lightning talk comes through I'll be able to chat with many high level folks about said support if it was possible to get things working before then. Alas it's 5 weeks away, so a bit tight on the timeline. I just bit the bullet and got a tutorial GDC pass.

If you could perhaps provide some guidance on where to start or what needs to be done I'll try to help out however I can. I can probably put in ~20 hours a week starting next week to help for the following 2 weeks then perhaps jam full time on things the remaining time as necessary to get things stable.

I'm finally getting a new dev laptop tomorrow and will be setting up the latest Android Studio setup in the next couple of days. What else will I potentially need? I assume getting comfortable with building LWJGL on the new lappy will be a good start (MacBook Pro in regard to environment). If there is any info regarding this process do point me to it as I didn't readily find anything on the LWJGL web site.

It'd be absolutely fantastic to get LWJGL 3 on Android and I'll pimp it hard at GDC and inform folks who is behind it all too (err not me!).  Grin I'll also foot the cost to make a nice color business card / flyer about LWJGL 3 w/ Android support info and pass it out to everyone I meet; will also include JGO link too!

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #6 - Posted 2017-01-19 20:17:10 »

Hey @Catharsis, here's a plan for what needs to be done:

1) Decide which ABI(s) we're going to support. I'd be happy with arm64-v8a and nothing else.
2) Cross-compile LWJGL natives to the target ABI(s).

This is the part I need more help with. The LWJGL build process uses Travis CI for the Linux binaries. The source code for each project is under the LWJGL-CI account on GitHub. Each repository has two branches (one for Linux x64 and one for macOS) with an appropriate .travis.yml script that performs the corresponding build. We'll need the same thing for Android (and Raspberry Pi builds later). Basically, a new branch must be created (e.g. master-android-arm64-v8a), which is exactly the same as the other two, except the contents of .travis.yml. The difficulty lies in getting Travis CI to cross-compile for our target ABI.

3) Change LWJGL so that it supports the new platform/ABI. (should be easy)
4) Test, fix, test, etc. (someone with Android dev experience: please contribute any information you might have!)
5) Deploy the new platform/ABI to Maven and the LWJGL site. (should be easy)

If this gets hard, we can focus on some LWJGL modules and skip the rest. At a minimum, we'll need:

- LWJGL core
- dyncall (the core depends on it)
- GLFW

Good to have:

- jemalloc
- OpenAL for audio

When building the core, unnecessary bindings can be disabled in /config/build-bindings.xml.

We should probably move this discussion to GitHub or the LWJGL on Slack.
Offline theagentd
« Reply #7 - Posted 2017-01-19 20:31:21 »

Err, no OpenGL module in that list?

Also, I assume there's no hope for Vulkan support on Android?

EDIT: And even if Vulkan is a no-go, I'd still use the sh*t out of LWJGL3 with OGL ES on Android.

Myomyomyo.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #8 - Posted 2017-01-19 21:13:59 »

OK.. I'll start taking a look ~mid-next week. I joined the slack channel as "typhonrt". I think starting with the core / bare minimum to get GLES up first is a good idea for sanity then add Vulkan and worry about audio later. I'm generally familiar with the process you outlined and will embrace the black screen of death until I make it blue..  Shocked  Hopefully Travis is up for it as with a cursory review it seems to indicate it may be a bit raw.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2017-01-19 21:38:39 »

Just a quick note... most RPis out there will be running a 32-bit Linux OS rather than a 64-bit one that the chips are able to run. Not quite sure what the implications are but I bet that means having to support a 32bit ABI for ARM.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #10 - Posted 2017-01-19 22:06:44 »

Err, no OpenGL module in that list?

I'm strictly talking about non-JNI code that needs to be built for Android. JNI code, especially in LWJGL, is trivial and can be easily built on any toolchain. Also, APIs like Vulkan have no dedicated JNI code in LWJGL; dlopen, dlsym and you're good to go.

Just a quick note... most RPis out there will be running a 32-bit Linux OS rather than a 64-bit one that the chips are able to run. Not quite sure what the implications are but I bet that means having to support a 32bit ABI for ARM.

Yes, noticed that in the quick look I had. There seems to be ongoing effort to support 64bit, but who knows when that'll be ready (RPi 3 only too). In any case, it is my understanding that Android binaries require a special toolchain that is not Linux compatible (correct me if I'm wrong please), so we'll need a different ABI for RPis anyway.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2017-01-19 23:41:07 »

If you had it working on Pi... would it be "headless"? As in, takes over the framebuffer? (I don't want to boot into Gnome or XFCE or whatever it's called)

Cas Smiley

Offline Spasi
« Reply #12 - Posted 2017-01-20 11:47:21 »

If you had it working on Pi... would it be "headless"?

Afaict, there are about 5 functions that must be called to launch EGL in "headless" mode. This is a trivial issue, these functions can be added to LWJGL in an afternoon. Or even called via dyncall without bindings.

The main problem is, as I said in the LWJGL forums, handling input without X. Keyboard, mouse, controllers, touch, we'll need something to handle all that. We cannot use GLFW, it supports 3 backends (X11, Wayland, Mir) and even though Wayland is supposed to be a lightweight solution (and works on RPi afaik), I think you'd want to avoid that too. So we'll have to go low-level. This is probably not that big of a deal, I mean, the main problem is identifying the APIs we need bindings for. Once we know how it's done, adding the bindings to LWJGL is going to be quick.

Which brings me to; I don't own an RPi and I don't know when/if I'll have time to do the above research. The easiest thing for me would be to get a list of APIs to add to LWJGL, from someone that knows what's necessary.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2017-01-20 12:30:09 »

I've got several Pis - one of each model in fact - and the time and wherewithal to test if you need me to.

Don't let input get in the way of development for now - produce a "dud" backend for it that simply fails to connect any devices successfully or something. Then at least I could get on with testing EGL.

Cas Smiley

Offline ziozio
« Reply #14 - Posted 2017-01-20 20:44:25 »

@spasi would the work I did on android and arm build before help here?
Offline Spasi
« Reply #15 - Posted 2017-01-20 22:09:28 »

Don't let input get in the way of development for now - produce a "dud" backend for it that simply fails to connect any devices successfully or something. Then at least I could get on with testing EGL.

Alright, will let you know once we have working ARM builds.

@spasi would the work I did on android and arm build before help here?

Yes, your config here should be a good start. Have you tried doing the same for any other library? I guess the hardest would be GLFW and OpenAL-Soft. They have plenty of dependencies other than the basic C libraries, which may or may not be readily available in a cross-compile toolchain.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2017-01-31 10:41:28 »

Hi Spasi, how are the ARM builds coming along? I should have time this month to play with the Pi. There's a good possibility we might be able to develop a passive display product based on a Pi+screen here.

Cas Smiley

Offline Spasi
« Reply #17 - Posted 2017-01-31 14:15:49 »

@KaiHH did the first successful build of lwjgl-core + bindings last night. We now have an android branch and I plan to start working on it asap. One dependency has also been built on Travis-CI.

The good news is that it's looking easier than we thought. The not-so-good news is that we're talking about Android builds. The Android NDK is supported out of the box on Travis-CI, but afaict we'll have to configure a cross-compile toolchain manually for generic Linux-ARM builds. Any help on that front would be much appreciated.
Offline Spasi
« Reply #18 - Posted 2017-02-03 18:25:11 »

The glxgears demo, ported to GLES 3 with lwjgl3 and JOML, running on...

Nexus 6P:

<a href="http://www.youtube.com/v/wC3LbPgtVY0?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/wC3LbPgtVY0?version=3&amp;hl=en_US&amp;start=</a>

Nvidia Shield:

<a href="http://www.youtube.com/v/3v9jpelfX6g?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/3v9jpelfX6g?version=3&amp;hl=en_US&amp;start=</a>
Offline KaiHH

JGO Kernel


Medals: 486



« Reply #19 - Posted 2017-02-03 19:19:19 »

The same demo on a HTC Nexus 9.
<a href="http://www.youtube.com/v/JpF_EdyQmWY?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/JpF_EdyQmWY?version=3&amp;hl=en_US&amp;start=</a>
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #20 - Posted 2017-02-05 18:51:09 »

Absolutely fantastic progress folks! I've still been tied up releasing TJSDoc (Javascript documentation tooling) and hope to get that finished this week then I'll pick up and start testing and using the Android LWJGL port full time+ for the remaining time leading into GDC. Here's hoping Vulkan comes online too! Grin Keep the info flowing and perhaps point out any pertinent details on where / how to get started with the current state of things. Got a wiki entry yet?

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #21 - Posted 2017-02-05 19:23:55 »

Everything is available in the android branch. Please note that we're force pushing regularly to clean up the commit history and whenever we sync with master.

If you clone the branch and run "ant compile-templates arr", it should produce a bin/android/lwjgl.aar file. Drop it in an Android project and it should just work. That's all there is to it right now. Next steps are: adding Android extensions that might be missing (in EGL, GLES and Vulkan), testing Vulkan, adding non-JNI natives (OpenAL-Soft, jemalloc, etc) and doing performance testing/tuning.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2017-02-05 19:29:17 »

Sterling stuff Spasi!

Cas Smiley

Offline Spasi
« Reply #23 - Posted 2017-02-10 22:48:48 »

Hello VKSurfaceView!

<a href="http://www.youtube.com/v/XAGi07iSbe8?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/XAGi07iSbe8?version=3&amp;hl=en_US&amp;start=</a>
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #24 - Posted 2017-02-11 23:38:14 »

Once again; this is huge! Amazing! Great work! I'll get in contact with Khronos to see if they'll let me do a quick ~3 minute announcement at GDC / Khronos tutorial day. I assume you can do the opengl.org blog announcement. Also I'll print up ~2k color business card (mini-flyers) with info on LWJGL going cross-platform to Android to pass out. Let me know if you have any logo / branding ideas or other input on graphics involved; I'll keep it classy. Any chance a permanent tutorial guide can be put up I can link to in addition to the main LWJGL web site; a Github wiki with screenshot walkthrough would be great! I'm still tied up for most of next week w/ the TJSDoc launch, but I'm going to get the word out at GDC. I'm sure I'll run into a bunch of Android bloggers too, so if some articles aren't up by GDC I'll see if I can drum up some interest.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #25 - Posted 2017-02-13 09:38:43 »

Hey Catharsis,

I'll work on this a bit more, mainly to clean up the code. There are two issues:

We currently require Android N and platform 24+. Which corresponds to too low a percentage of Android users. Making it work on earlier versions should be possible, but I have neither the energy nor the incentive to do it myself. Not sure if it's even worth doing, given the performance characteristics (I'll write another post with the details).

There's also the issue of better handling buffer/device lost events, which are fairly common with Vulkan on Android. You may notice it in the above video, when the orientation changes, there's a full destroy and recreation of the whole thing. Moving out of the app and back in again also requires a "soft-reset", but I think I've handled that one sufficiently.

The issue is complicated by the fact that I've written VKSurfaceView similarly to GLSurfaceView; everything runs on a separate thread and the UI events arrive asynchronously. If you're familiar with GLSurfaceView's implementation... it's not trivial and I don't have the necessary experience (or time) to make it robust. If I fail, I'll probably make another version that runs on the UI thread and maybe Android engineers can help with properly fixing the concurrent version.

Once that's done, I'll update the lwjgl3 android branch and will create another repo with an Android Studio sample project and some instructions.

Other than that, I won't have time for much else. I'm fairly busy at work and I'm also becoming a father for the 2nd time (today or tomorrow). I'm also not really comfortable with announcing what is essentially a work-in-progress. And it's not like LWJGL needs that much branding/marketing. People that need to go low-level can easily find it, there aren't many options out there. I certainly don't want to give the illusion that it's a library for the average developer. Especially wrt Vulkan.

I'll pm you links to LWJGL's logo in various formats.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #26 - Posted 2017-02-13 21:24:16 »

We currently require Android N and platform 24+. Which corresponds to too low a percentage of Android users. Making it work on earlier versions should be possible, but I have neither the energy nor the incentive to do it myself.

From my perspective this is fine as Google constantly introduces new SDK APIs that aren't available at lower platform levels. In the coming months I will try and see if things can be back-ported at least for GLES to platform 19 (4.4 / KitKat / GLES 3.0); I'm generally aware of the problems / efficiency though of pre-OpenJDK though. Vulkan itself has more or less a limitation of Android N regardless if going native or through LWJGL, so again not so much of an issue with platform 24.

The amazing part of LWJGL being on Android is that now there is an option for low level graphics that is separate of the SDK / firmware conundrum of how previous SDK graphics APIs are managed. IE As the Vulkan spec continues to be modified we don't have to wait for platform 25, 26 ... X to get these new features enabled like previous Java SDK efforts being locked to the firmware. Granted there are still firmware locked drivers, but if it's an advancement of the Vulkan API itself that isn't dependent on driver updates then these new features will always be available at platform 24.

Not sure if it's even worth doing, given the performance characteristics (I'll write another post with the details).

When you get a chance this will be much appreciated and will provide initial metrics to compare for any back-porting.

There's also the issue of better handling buffer/device lost events, which are fairly common with Vulkan on Android. You may notice it in the above video, when the orientation changes, there's a full destroy and recreation of the whole thing. Moving out of the app and back in again also requires a "soft-reset", but I think I've handled that one sufficiently.

That you got this mostly worked out initially is great work. However this is not an issue as since day 1 with GLES on Android 1.0 onward one simply locks the orientation for game / graphics apps. Very few intense graphics apps don't lock the orientation and and leave the orientation restart process enabled.

I can perhaps see the difficulty of enabling various debug layers of Vulkan and getting all the necessary output perhaps if it's not being logged per se, but that is a separate issue.

The issue is complicated by the fact that I've written VKSurfaceView similarly to GLSurfaceView; everything runs on a separate thread and the UI events arrive asynchronously. If you're familiar with GLSurfaceView's implementation... it's not trivial and I don't have the necessary experience (or time) to make it robust. If I fail, I'll probably make another version that runs on the UI thread and maybe Android engineers can help with properly fixing the concurrent version.

I wouldn't hold my breath per se for any Android engineers being involved; I don't think there are any more Java / graphics champions involved to a meaningful degree on the Android team. If there is collaboration though it will be embraced warmly!

I do have experience in creating an updated GLSurfaceView2, so I'll take a look in time on any improvements there as well for VKSurfaceView, etc. If I recall correctly it was necessary at the time to expose GLES 3.1 since the Android SDK GLSurfaceView is based on the old EGL API (
javax.microedition.khronos.egl.EGL10) instead of 1.4 (android.opengl.EGL14).

Once that's done, I'll update the lwjgl3 android branch and will create another repo with an Android Studio sample project and some instructions.

If the repo can be created sooner than later along with a wiki entry where instructions will go then I can proceed with the mini-flyers.
I'll also gladly contribute the screen shot walk through of setting things up similar to what I did for my GL demos /  source code setup.

Other than that, I won't have time for much else. I'm fairly busy at work and I'm also becoming a father for the 2nd time (today or tomorrow).

Congrats with your new child! I'm always amazed that you consistently move LWJGL and the larger community forward so deftly in your spare time!

It shows that any backpedaling on Google's side is simply that; a lack of will to get things done. It's kind of been that way for a while now as things go. Your effort with LWJGL on Android means that Java will remain a first class citizen for modern app development and this is huge.

People that need to go low-level can easily find it, there aren't many options out there. I certainly don't want to give the illusion that it's a library for the average developer. Especially wrt Vulkan.

I agree the average game developer for a long time now has moved away from engine development.

In this case though the Khronos tutorial day is filled with folks making up the right audience to send a message to and that is Java remaining a first class citizen for advanced graphics development on Android and LWJGL filling the need for a unified cross-platform SDK for low level access which fulfills the promise of Vulkan and is something Google would never do re: one Java API that runs on the desktop and Android.


Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #27 - Posted 2017-02-14 19:09:48 »

The amazing part of LWJGL being on Android is that now there is an option for low level graphics that is separate of the SDK / firmware conundrum of how previous SDK graphics APIs are managed. IE As the Vulkan spec continues to be modified we don't have to wait for platform 25, 26 ... X to get these new features enabled like previous Java SDK efforts being locked to the firmware. Granted there are still firmware locked drivers, but if it's an advancement of the Vulkan API itself that isn't dependent on driver updates then these new features will always be available at platform 24.

Yes, totally agree. But it would be nice if this decoupling benefit could be extended to developers that target OpenGL ES and earlier API levels.

However this is not an issue as since day 1 with GLES on Android 1.0 onward one simply locks the orientation for game / graphics apps. Very few intense graphics apps don't lock the orientation and and leave the orientation restart process enabled.

Good point.

I can perhaps see the difficulty of enabling various debug layers of Vulkan and getting all the necessary output perhaps if it's not being logged per se, but that is a separate issue.

That's actually very easy; the NDK includes precompiled layer libraries that you can simply drop in your project. Vulkan validation works just fine.

I don't think there are any more Java / graphics champions involved to a meaningful degree on the Android team. If there is collaboration though it will be embraced warmly!

It doesn't have to be Java developers. Anyone that writes a Vulkan app, either in Java or C, will face the same issues.

Actually, I couldn't find a Vulkan sample in the official repo that handles surface destruction properly. I could just as easily call this "not my problem" and actually I don't plan adding VKSurfaceView to lwjgl3. But it'd be very nice if we could provide a sample project that handles some of the complexity and exposes an API that's familiar to anyone that has used GLSurfaceView.

If the repo can be created sooner than later along with a wiki entry where instructions will go then I can proceed with the mini-flyers.
I'll also gladly contribute the screen shot walk through of setting things up similar to what I did for my GL demos /  source code setup.

Will try to get it ready asap.
Offline Spasi
« Reply #28 - Posted 2017-02-17 11:01:20 »

Disclaimer: I'm an Android noob and it's entirely possible that I missed something important.

Here are my performance findings on Android. All tests were done on a Nexus 6P running Android N 7.1.1. The app was deployed as a signed APK, release variant, minimum platform 25. Metrics were printed with Android's Log and retrieved using logcat:

A general remark first. ART's JIT compilation is underwhelming. I'd say roughly equivalent to a Java client VM from a decade ago. Which I have a hard time believing given how experienced Google is with VMs and JITs (V8 is more than impressive). My first instinct while doing tests was that the app was always running in 100% interpreter mode. But no matter what I tried, it didn't get any better. I even left the app installed overnight, maybe the offline ART AOT would do some magic, but nothing improved. I really hope I'm missing something simple. The hardware feels pretty powerful and I don't think doing basic optimizations would waste that much battery.

- The first problem that affects LWJGL is that ART is not able to treat static final fields that are initialized at runtime as constants. This affects primitives (e.g. compiling away normal and debug mode checks that are behind static final booleans) and calls to interfaces with a single implementation instantiated at runtime (static final AnInterface FOO = new AnImpl()). Hotspot is easily able to de-virtualize such calls and fully inline them. This is critical for LWJGL performance in several cases.

- The above issue can be mitigated using ProGuard optimization passes. Which, again, takes us back a decade or more. It cannot even be done once for LWJGL, it needs to run on every build of the user's app, making builds horribly slow. The performance improvement is substantial though. ProGuard is able to inline and devirtualize a lot of code. The worse your JIT is, the more difference this makes.

- ART does not perform escape analysis. This I was expecting, but think it's worth mentioning. No EA means LWJGL users must be careful with allocations. The MemoryStack should not be used in tight loops, struct buffers should be accessed with the flyweight pattern, etc. This, again, means writing Java 1.4 era code, preallocating and reusing buffer instances etc.

- LWJGL depends on Unsafe and intrinsics for many things. For Vulkan in particular, that is an API heavy on structs, LWJGL uses Unsafe to access all struct members. The good news is that Android 7 supports the full Java 8 Unsafe API and has proper intrinsics. Measuring simple reads/writes produces appropriate results for the underlying hardware. The first problem is inlining: properly encapsulating Unsafe sacrifices a lot of performance without ProGuard. The second problem is a bug on Aarch64: it's impossible to access > 32bit memory addresses with Unsafe, the address is getting masked out at 32bits. This won't affect most app allocations, but all libraries are mapped to a >32bit address and any memory provided by them will be in that range.

- Android has another internal API similar to Unsafe, libcore.io.Memory. This class is also intrinsified and doesn't suffer from the same bug. Unfortunately, it's about 4x slower than Unsafe in my tests.

- The java.nio buffer implementation on Android is bad. Too many allocations, too much overhead, they use libcore.io.Memory instead of Unsafe. Accessing anything via a buffer is 10x slower than the equivalent Unsafe access.

To sum up, it feels like Java on Android is meant to be used for client UI code only. Anything performance sensitive should be moved to JNI and native code. Making Java+LWJGL a decent alternative will take some work and I'm not sure if it can be done within the official repo or better moved to a fork. E.g. one solution to the last point is writing a custom buffer API, which means the entire LWJGL API needs to change. Actually, getting rid of NIO was something that I briefly consider doing when I started lwjgl3 (it would benefit desktop apps as well), but decided it was more important to keep compatibility with the lwjgl2 bindings.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2017-02-17 11:19:19 »

What about OpenJDK (Zulu) on Android?

Cas Smiley

Pages: [1] 2
  ignore  |  Print  
 
 

 
Ecumene (149 views)
2017-09-30 02:57:34

theagentd (214 views)
2017-09-26 18:23:31

cybrmynd (300 views)
2017-08-02 12:28:51

cybrmynd (288 views)
2017-08-02 12:19:43

cybrmynd (296 views)
2017-08-02 12:18:09

Sralse (291 views)
2017-07-25 17:13:48

Archive (968 views)
2017-04-27 17:45:51

buddyBro (1094 views)
2017-04-05 03:38:00

CopyableCougar4 (1667 views)
2017-03-24 15:39:42

theagentd (1428 views)
2017-03-24 15:32:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!