Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Vulkan Game Engine  (Read 3527 times)
0 Members and 1 Guest are viewing this topic.
Offline DesertCoockie
« Posted 2018-02-21 11:30:30 »

Are there any Java Game engines, using Vulkan?
Personally I haven't found one, even though it would be a really interesting alternative to OpenGL in the Java gaming scene.
Offline zngga
« Reply #1 - Posted 2018-02-21 23:41:46 »

Doesn't LWJGL3 have Vulkan bindings?

Or do you mean an Engine in the scope of something like Unity?

My code never has bugs... it just develops unexpected features!
Offline delt0r

JGO Wizard


Medals: 143
Exp: 18 years


Computers can do that?


« Reply #2 - Posted 2018-02-21 23:56:51 »

lwjgl 3 does have vulkan bindings. However there is no "engine" per say. I guess you could add a backend to Java Monkey Engine. But since that has a lot of "gl" type rendering, you may not see any real world benefit. In fact in general i wouldn't expect much difference between Vulkan and gl. Is there any particular reason?

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DesertCoockie
« Reply #3 - Posted 2018-02-22 10:31:50 »

Or do you mean an Engine in the scope of something like Unity?
I mean more like LibGDX or something. Unity and Co are quite big engines to take on, using something like LWJGL.

In fact in general i wouldn't expect much difference between Vulkan and gl. Is there any particular reason?
Well, with Vulkan it takes a lot more effort to do the same as in OpenGL, but frame fates can be significantly higher. Especially the multithreading is interesting in my opinion.
I just was curious if somebody already has begun making that hard and time expensive ground work and build a easy to use engine around it.
Offline princec

« JGO Spiffy Duke »


Medals: 1030
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2018-02-22 10:58:08 »

My 2p on Vulkan and Java is maybe wait until value types are a thing before you go attempting to chase performance, as Java is always going to be horribly hobbled by its objects model and buffer IO.

Cas Smiley

Offline Spasi
« Reply #5 - Posted 2018-02-22 15:26:14 »

Java is always going to be horribly hobbled by its objects model and buffer IO.

This would be true with typical JNI bindings. LWJGL bindings are not typical. This is what Vulkan code that runs at 5000fps looks like with LWJGL:



See those crossed out lines? They are Java allocations that have been eliminated with escape analysis. After scalar replacement, all that remains in the JITed code is a pointer address. Here's the list of eliminations in the entire hot path:



It is possible to write high performance Vulkan applications with LWJGL, with no Java allocations (escape analysis) and no native allocations (MemoryStack "allocations" are simple pointer additions/subtractions). In fact, almost every major decision that has shaped lwjgl3's API and internals, has been made to support writing and running Vulkan code efficiently.
Offline princec

« JGO Spiffy Duke »


Medals: 1030
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2018-02-22 15:33:19 »

It's a pain in the arse manually serializing data into buffers though innit? And not to mention all the other irritating high-efficiency woes of Java objects that ruin stuff like particle systems. So I'm just saying... wait it out a bit, value types will come along and then you won't feel like having to rewrite everything to use them when they happen.

Cas Smiley

Offline Spasi
« Reply #7 - Posted 2018-02-22 15:53:51 »

There's no manual serialization in the classic serialization sense. That's just how the Vulkan API works. Instead of many functions with many parameters like in OpenGL, you have fewer functions and many structs (literally hundreds of them). You fill the struct members, you pass it to a function (that's why EA works well).

Value types won't change anything in the API. The JVM won't need to do EA for performance and maybe my life as a library maintainer will be easier, that's all.
Offline Spasi
« Reply #8 - Posted 2018-02-22 16:03:28 »

Just to be clear, I can't wait for value types for normal Java code. It's incredibly exciting, considering that we'll also get generics with value specializations (List<int> anyone?). But they won't do much for native interop. We need Project Panama for that.

The interesting thing is that compute heavy stuff like particle systems also need Project Panama. Removing object header overhead and pointer indirections is cool. SIMD vectorization for 7-8x speedups is much cooler. Automatic vectorization is not cutting it, there are so many annoying limitations, even on latest Java 10 builds.
Offline princec

« JGO Spiffy Duke »


Medals: 1030
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2018-02-22 16:13:58 »

Yeah, absolutely. I can't wait either. I'm just thinking that when the JVM manages to put so many irritating slow obstacles in your code elsewhere, it seems a bit pointless chasing the efficiency gains in Vulkan at this time as you'll just end up bottlenecked elsewhere by Java.

(By serialization I meant, writing vertex data out into NIO buffers painstakingly manually - a massive arse, prone to error, hard to debug, etc)

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline h.pernpeintner

JGO Knight


Medals: 82



« Reply #10 - Posted 2018-02-23 16:20:35 »

(By serialization I meant, writing vertex data out into NIO buffers painstakingly manually - a massive arse, prone to error, hard to debug, etc)

Yes, everyone will somewhen get to this problem when doing engines/higher performance stuff with Java that goes beyond basic games. I wrote an abstraction for myself for exactly this purpose, which is kind of a StructuredBuffer<T extends Bufferable>. It's not as nice as using the objects directly, but hey, it's okay for the few cases where one really needs it. Debugging is afterwards just fine with implementing buffer fetches for an object type/printing it. I think it's okay, if everything else works on the given performance levels. Combined with the memory utils of LWJGL, I managed to get pretty much rid of "ugly" code and allocations.
Offline Spasi
« Reply #11 - Posted 2018-02-26 14:51:27 »

MoltenVK has been open-sourced, macOS is now a fully supported platform for Vulkan applications.
Offline princec

« JGO Spiffy Duke »


Medals: 1030
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2018-02-26 16:02:34 »

w00t! I might even consider learning it now.

Cas Smiley

Offline DesertCoockie
« Reply #13 - Posted 2018-02-26 21:52:07 »

Yees! That's actually awesome! It would make it worth to me now too.
Offline Spasi
« Reply #14 - Posted 2018-03-03 17:29:57 »

The first LWJGL 3.1.7 snapshot is now available with Vulkan 1.0.69 and MoltenVK. If you're on macOS, add this to your Maven script:

1  
<dependency><groupId>org.lwjgl</groupId><artifactId>lwjgl-vulkan</artifactId><version>3.1.7-SNAPSHOT</version><classifier>natives-macos</classifier></dependency>


or equivalent for Gradle/Ivy, or get it from lwjgl.org.

A new binding has also been added: the Vulkan Memory Allocator (lwjgl-vma module). It simplifies CPU & GPU memory management of Vulkan applications.
Offline DesertCoockie
« Reply #15 - Posted 2018-03-08 07:53:26 »

Just found this article that brings up a lot of interesting things and wanted to share it:
https://www.anandtech.com/show/12465/khronos-group-extends-vulkan-portability-with-opensource
Offline KaiHH

JGO Kernel


Medals: 520



« Reply #16 - Posted 2018-03-08 09:12:53 »

First read, then post: http://www.java-gaming.org/topics/vulkan-game-engine/38598/msg/368512/view.html#msg368512
Offline DesertCoockie
« Reply #17 - Posted 2018-03-25 13:13:29 »

There is a lot more in the article, that's why I shared it. You could've read it first too  Cheesy
Offline KaiHH

JGO Kernel


Medals: 520



« Reply #18 - Posted 2018-03-25 13:24:35 »

You did not get what I was referring to. By the way, I also found another great article which noone in this thread has shared yet, which I would like to share. Please read this as well ;-)
Offline Spasi
« Reply #19 - Posted 2018-03-26 14:57:27 »

This looks interesting: V-EZ. More information: V-EZ brings "Easy Mode" to Vulkan
Pages: [1]
  ignore  |  Print  
 
 

 
DesertCoockie (53 views)
2018-05-13 18:23:11

nelsongames (84 views)
2018-04-24 18:15:36

nelsongames (75 views)
2018-04-24 18:14:32

ivj94 (760 views)
2018-03-24 14:47:39

ivj94 (88 views)
2018-03-24 14:46:31

ivj94 (644 views)
2018-03-24 14:43:53

Solater (103 views)
2018-03-17 05:04:08

nelsongames (185 views)
2018-03-05 17:56:34

Gornova (427 views)
2018-03-02 22:15:33

buddyBro (1087 views)
2018-02-28 16:59:18
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!