Libgdx: Feature request - Vulkan (after released)

[mars3142]

It would be nice, if libgdx could use Vulkan on Android, after the release. More about it on http://android-developers.blogspot.de/2015/08/low-overhead-rendering-with-vulkan.html

More background information: http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

[badlogic]

It would indeed be nice, but that would mean the Android backend would no
longer be compatible with the libGDX interfaces that directly expose OpenGL
ES.
On Aug 11, 2015 11:38 AM, "Peter Siegmund" [email protected] wrote:

It would be nice, if _libgdx_ could use _Vulkan_ on _Android_, after the
release. More about it on
http://android-developers.blogspot.de/2015/08/low-overhead-rendering-with-vulkan.html

More background information:
http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

—
Reply to this email directly or view it on GitHub
https://github.com/libgdx/libgdx/issues/3344.

[GreenLightning]

Maybe it's time for LibGDX 2.0?

[nooone]

^

[xoppa]

I'm very curious to play around with vulkan. But currently we probably should first make opengl es 3.0 support more robust.

[JesseTG]

Vulkan isn't really intended to replace OpenGL anyway, is it? In that case, why not both?

[badlogic]

Are you going to maintain it? :D
On Feb 19, 2016 8:30 PM, "Jesse Talavera-Greenberg" <
[email protected]> wrote:

Vulkan isn't really intended to replace OpenGL anyway, is it? In that
case, why not both?

—
Reply to this email directly or view it on GitHub
https://github.com/libgdx/libgdx/issues/3344#issuecomment-186369571.

[intrigus]

You'll get access to Vulkan on the desktop via LWJGL3.
I'm not exactly sure why everyone wants Vulkan, because it's very explicit and verbose ^^

[SaeedMasoumi]

With Android N release (preview 2), They made Vulkan a part of the platform.
http://developer.android.com/intl/zh-cn/preview/api-overview.html?#vulkan

[kerberjg]

I agree with @SaeedMasoumi; also Google has already started writing docs for the Vulkan API in Android (http://developer.android.com/ndk/guides/graphics/index.html), which already gives us a base to work on.
With LWJGL3 supporting Vulkan as well, all the conditions should be clear. We can at most keep backwards compatibility for OpenGLES for iOS until they make the transition too

Also bigger companies like Unreal Games, Valve and similar are already making the transition to Vulkan. Since Google is starting to support it as well, I think it's our chance to get ahead of the curve and start implementing it in LibGDX.

Also, @xoppa, given how things are going I don't think it's worth to evolve the support for OpenGLES (3.0) as it's already getting obsolete.

EDIT: I'm asking this issue to be reopened for future developments
EDIT2: The WSI looks like a quite interesting thing to work with

[intrigus]

Vulkan is absolutely NOT going to replace OpenGL nor OpenGLES.

I don't unterstand why everybody want's Vulkan. Just because it's 'new'?
Using Vulkan means that a simple rotating triangle demo has 2k loc.
If you really need Vulkan for speed, you have to know how Vulkan works. (Why else would you use it)
When you know how Vulkan works, you should also be able to build a cross-platform Vulkan wrapper yourself. (Because Vulkan is extremely verbose and explicit and for advanced programmers)

If you absolutely want Vulkan in libGDX, you are free to fork libGDX and create a PR AND to maintain the Vulkan code.

You also have to remember that Vulkan does NOT automatically make your game faster. It can even make it slower!

[cyraid]

People want Vulkan so they can be in control of the threading themselves, and so it can be a more predictable fps. P.S. how's the progress on this?

[badlogic]

Vulkan will never happen in libGDX.

On Jul 4, 2017 11:43 AM, "cyraid" [e-mail] wrote:

People want Vulkan so they can be in control of the threading themselves,
and so it can be a more predictable fps. P.S. how's the progress on this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3344#issuecomment-312833817, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfYBIYEypyyBRBaYeIkSfwHG5A3RmOAks5sKgkjgaJpZM4FpWHo
.

[cyraid]

Well I was gonna offer to put in vulkan support myself, and actually make a game editor with libgdx.. but guess with that attitude, I'm out. Enjoy guys.

[badlogic]

All rendering code in libGDX is based on the GLES API. Adding Vuokan would
require a complete rewrite of all rendering code, which would essentially
mean an almost rewrite of libGDX.

This is not an attitude problem, but a matter of practicality.

On Jul 4, 2017 5:42 PM, "cyraid" [e-mail] wrote:

Well I was gonna offer to put in vulkan support myself, and actually make a
game editor with libgdx.. but guess with that attitude, I'm out. Enjoy guys.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3344#issuecomment-312907537, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfYBEpHXi-kihwztWZvaoFo7Lt8Ewlrks5sKl1SgaJpZM4FpWHo
.

[terefang]

you might want to watch https://github.com/Think-Silicon/GLOVE as GL/ES over Vulkan