IssueTracker

Thanks for posting this issue as I was about to file a similar issue.

I have an advanced Java / GLES based video engine (www.typhonvideo.com) I was considering moving to Vulkan if possible; mostly interested in compute support of Vulkan amongst enhanced multithreading.
Given that the video engine relies on the GLES / MediaCodec integration introduced in 4.3 of course that could be a snag as well as it is likely that may have to updated as well for Vulkan support via a Window System Interface (WSI) / Vulkan extension. Specifically this EGL extension powers the GLES / MediaCodec integration:
https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

Outside of a full screen Java / SDK use case it would be nice to also have a TextureView or a new "VulkanView" which could integrate Vulkan in a way that behaves as a regular View.

It seems like there may be an LWJGL build that works on Android soon:
http://www.java-gaming.org/topics/engaging-the-voyage-to-vulkan/37041/msg/355302/view.html#msg355302

The main Vulkan / LWJGL progress thread is here:
http://www.java-gaming.org/index.php/topic,37041

Internally to Google it seems like there are few / no Java / SDK / graphics champions as things go. Please don't let the Android SDK fall behind! There are advanced Java / SDK based devs that can use Vulkan and we want it!

[Comment deleted]

[Comment deleted]

Hi,
We have passed this request on to the development team and will update this issue with more information as it becomes available.
Thanks

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. If there is enough demand we should design a Java-language graphics API that is explicit and multi-threaded (and implemented on top of Vulkan), but that fits better stylistically with other Android APIs and has less undefined behavior / stronger guarantees.

The JNI overhead statement is kind of moot and a straw man argument considering bulk transfer of data with few calls is the standard approach for modern OpenGL/ES from Java or a Vulkan binding. Vulkan brings many more opportunities regarding memory allocation / transfer. Furthermore features such as reuse of command buffers and parallel command buffer generation when they do need to be regenerated per frame of Vulkan provide ample opportunity to significantly reduce the overhead encountered in OpenGL/ES via a Java API.

Please try harder and think a little deeper as the JNI overhead argument does not stand up to scrutiny.

A separate graphics API built on top of Vulkan will not be desirable at all considering cross-platform usage. This will get about as "warm" of a reception as Renderscript especially if it is not aligned in a way to assist in a cross-platform nature.

A Java API that is cross-platform or at the very least to the extent possible such that a facade between different backing implementations can be created between for instance LWJGL on the desktop and whatever future Android API for Vulkan access is desirable. There is an unknown timeline for LWJGL to run on Android since there is a desktop focus for this framework. If a single developer who is behind the bulk of the hardcore work of LWJGL can create an efficient Java binding to Vulkan in about a month so can the Android team. The only thing lacking from Google is the will to do it.

Don't assume that Java based Android developers are too stupid or can't handle the Vulkan API. This has kind of been the general sentiment that I've picked up thus far from Google.

Please reopen this issue and go back to the drawing board regarding an Android / Java Vulkan binding.

So, the community has come through as LWJGL has been ported to Android including a Vulkan binding! This work was done over about a month in spare time by Ioannis Tsakpinis, core developer of LWJGL. While it's early days for LWJGL on Android this really is the way forward for modern Java based graphics apps on Android. Right now platform level 24/25 is necessary for Vulkan support and LWJGL in general. In the coming months hopefully, though not guaranteed, GLES support could extend back several platform levels as well. Here is the Android test repo with GLES and Vulkan examples: https://github.com/LWJGL/android-test

I'll be working on getting an expanded wiki entry up soon with detailed walkthrough with graphic snapshots of the process of setting up, building and running the tests.

This is a huge win ensuring that Java remains a top level language for modern apps on Android. There is now one API to target on the desktop and Android which is huge. It also brings a much needed separate binding to low level graphics separate of the Android platform locked SDK releases; IE updates to the Vulkan and GLES APIs can be released separately to platform releases of Android as long as existing drivers support the changes.