Hi,
Vulkan 1.0 is offcially released, and here is the link Vulkan Overview - The Khronos Group Inc .
I’m really excited about it, this should bring so much improvements when used proprelly.
I am currently following their tutorial to get used with the API, and I’ll certainly include it to my Engine in the future.
Any plan for JME3.x to support it ? I’ll surely contribute if so. 
I didn’t have the time to dig deeply into it but I guess it’s a matter of jogl/jwjgl to support it first.
And it will be quite some job to change parts of the engine.
I have two questions myself:
Will openGL be deprecated (anywhere soon?)
Is it reasonable to wait buying a new GPU for a few months now?
Because my theory is, that current GPUs run off openGL/DirectX and would emulate the Vulcan API, so it’s better when they are native? Or did they already have the specification long time ago?
Will openGL be deprecated (anywhere soon?)
No way, OpenGL is still fully supported by the Khronos Group. Vulkan and OpenGL target different developpers (Even though they are both Graphics API). Vulkan is more low level (but more complex).
For you second question :
Initial specifications state that Vulkan will work on hardware that currently supports OpenGL ES 3.1 or OpenGL 4.X and up. (Wikipedia)
But I dont think waiting until jogl/lwjgl supports it to begin thinking about including it in jme3 is a good idea. At least the part where they re-design the architecture of the Engine should be done before. (because it’s needed.)
So no improvements? 
Haha for people like me, unfortunately yes
Seems to me like Vulkan is to assembly language as OpenGL is to C. They will both coexist and it seems obvious to me that OpenGL implementations will start to be built on top of Vulkan instead of separately coded. Perhaps this fixes a lot of problems.
It may be that JME3 doesn’t ever need to support Vulkan directly because it’s already a higher level abstraction. (One need only look at some of the ‘draw a triangle’ Vulkan examples to know that’s a way more complicated beast.)
Edit: Note… if anyone ever wondered what would prompt a JME4 then it would probably be Vulkan based, I guess. 
I think we have a few years to worry enough about hardware penetration for that.
1 Like
Might fit here… saw it on twitter. Original link:
https://pbs.twimg.com/media/CbSTzEjXEAEJVPt.jpg:large
Imgurified version:
1 Like
In Khronos’ presentations at SIGGRAPH and GDC, this was explicitly discussed. IIRC, there is going to be an official implementation of openGL on Vulkan. Since Vulkan is a simpler, lower level API (to build, not use!) It’s thought that hardware manufacturers will have a much easier time building and maintaining a standard Vulkan driver.
Leads to better support, and updates to openGL can be deployed without waiting for hardware drivers to catch up.
Hi
FYI : LWJGL adding Vulkan bindings in their latest nightly build (3.0.0 #24).
https://github.com/LWJGL/lwjgl3/commit/9fb7bcc0b9611185714820536d643c2e5fed9cce
http://forum.lwjgl.org/index.php?topic=6144.msg32847#msg32847
Hi
Thought you might be interested in benchmark of Unity with Vulkan on Android
Benefits
The main benefit of Vulkan over older mobile rendering APIs such as OpenGL ES 3.x is speed.
Vulkan is designed to take advantage of multiple CPU cores by allowing
the application to build command lists in multiple threads in parallel.
This allows the application to take advantage of all of the CPU cores on
the device, improving performance. The Vulkan preview release supports
this via the “Enable Graphics Jobs” checkbox in the player settings.
However, we’re seeing large performance gains even when running the
renderer in a single thread. In one of our internal benchmarks we’re
seeing up to 35% improvement in frame times on Android, compared to OpenGL ES 3.1 renderer, even though they’re both running in a single rendering thread!