Just saw the new extension on github. I guess it will require v 1.2.171?
Can’t wait 
3 Likes
Yes, the plan is to “release” it as an extension next release.
You can in fact already use it, since we’ve been testing it for a while.
Now we want our community to test it as well, so that we can find any odd cases where it doesn’t work as intended.
Some notes:
- We support Metal for iOS/OSX using MoltenVK (a Vulkan->Metal wrapper)
- The extension merely handles the “linking” with the correct libraries, adding a vulkan backend.
- It does not come with a full new rendering api for the render scripts. That is on the roadmap though.
- If vulkan isn’t supported on your platform, it will fallback to the OpenGL version (if you didn’t remove it with an app manifest)
9 Likes
Just curious; do we expect to(or did you) see any performance improvements on Metal platforms?
1 Like
Tbh, I don’t really expect to see a performance gain, due to the fact that we do things the “opengl way”, in order to simply have a Metal backend. I.e. we have our internal “dmGraphics” api, and we now have two backends for it.
I think in the future, when we have a render2 renderscript, which allows you to do things the “vulkan way”, it will open up for more improvements.
I don’t remember if @jhonny.goransson saw any performance gains with this current implementation.
4 Likes
Our Vulkan implementation has been tested by engineers from both ARM and Samsung and we got excellent feedback and very good remarks on our implementation. We’re in a good place once we decide to create a new render API.
11 Likes
Oops I’m a bit late to the party, but no not really any performance gains right now since we are forced to shoehorn the layer within the current rendering API which is very much based on how OpenGL is designed. I hope to get around to build a more modern API around vulkan where you should be able to gain a bunch of performance. However, one benefit right now is that you get access to a bunch of new shader features since we have to upgrade the shaders in the pipeline in order to cross-compile the glsl to spirv.
10 Likes
I remember you talking about this before but don’t remember the details… Could you share what kind of features these are again?
1 Like
I think it’s a best topic to discuss Vulkan a little bit. I had in mind this extension, but never actually used it, but since I’m trying to make a video about rendering I feel obligated to at least mention it. And because it’s “at least” I would like to know more about it.
So one Tweet is interesting, Tomasz is one of the makers of this amazing building tool/game:
And he mentions improvements after switching from OpenGL to Vulkan.
Does anyone in Defold community did something with Vulkan? (I think it is required for Switch releases, right?) Any insights or experience would be good to read! 
Nothing fancy but I was curious to see the performance difference when using shaders. So when I was porting Pixel Planet shaders from Godot, I mess with it. There was a quite performance improvements even on my old macbook air against opengl. I didn’t touch this project for a while but It has vulkan manifests, so you can test with it.
1 Like
You should be able to test this yourself by creating an app manifest where you enable Vulkan. Or the other approach is to add extension-vulkan to your project.
1 Like
The reason why we implemented the vulkan layer in the first place was because of apple deprecating OpenGL and we didn’t want to box ourselves in with just implementing a Metal layer as Vulkan is cross-platform. So MoltenVK would solve that for us and we could make a transition over time over to Vulkan/MVK as the main graphics implementation.
But that hasn’t happened (yet) due to the fact that our render scripts are modeled as a thin abstraction over the OpenGL state machine, which doesn’t map well to a modern graphics API such as Vulkan in terms of performance. So right now I would be a bit surprised if you notice a performance gain with Vulkan since we can’t really use it to it’s full potential because of our render api. Our intention over time is to build a new render API that maps better to the modern APIs (bindless textures, indirect rendering, command buffer generation, better uniform buffer support etc) but right now there’s not a whole bunch of benefits with using the vulkan layer, except for a few things:
- you can use better profiling tools
- you can use newer glsl functions like sampling specific lods
- developing new graphics features in the engine is a lot easier since vulkan has way better validation
- implementing new graphics APIs is a lot easier since we have already laid the groundwork for certain things like context creation and graphics adapter separation
All in all the idea is to do more with the Vulkan api than we are doing right now, but I can’t say when. I have ideas 
7 Likes
I guess the rendering panorama has been getting a bit fragmented lately. Have you looked at webgpu as well? That has a native spec/implementation although is still not embraced in browsers
Yes, I saw that chrome has some kind of beta version available in one of their browsers. I’m hoping that emscripten has a vulkan wrapper that we could use, otherwise I don’t think we’ll have time for it for a while… there’s a lot of talk on twitter regarding wgsl and that everyone (gamedevs) hates it but I haven’t looked closely yet
3 Likes