 Hi guys, I'm Juan, going to do this talk. Before we start, we didn't start yet. Before we start, I wanted to ask just, I can tailor it a bit better for your needs. How many of you guys actually like or are enthusiast or go about like rendering? You guys, if you can raise your hand, how many like rendering? Okay, that's quite a good amount. Okay, how many of you that do rendering actually are interested in Vulkan? Okay, that's a good amount. How many actually understand Vulkan? Not so many. Okay. Then I won't go into that many super low-level technical details of Vulkan because it can be. We tried this a few months ago and it didn't end very well because Vulkan is a bit difficult, takes a while. So we still have a bit more time, I guess. Five minutes, okay. So that's okay. Well, nice to see so much interest in rendering. Yes, when it's worried that today, you see a lot of game engines and including a lot, and that people won't be interested anymore about rendering, but nice to see that you guys actually like it. So how many here have used a lot? Oh, nice. Good to see so many of the users. Keeps growing every year. That's nice. Nice to that you're here and not in a global game jam, at least that's it's something. So the talk will be mostly about the kind of things that we take advantage of using Vulkan. I think when Vulkan came out three years ago, it wasn't very clear what it was for because you had OpenGL, it worked. There was DirectX 11 and DirectX 12 was still something new and nobody really quite got what it was about. When we saw Vulkan, we were like, what is this for? So we took a while actually to get the engine to be ported to Vulkan. It's still in the process. We learned a few bad things about OpenGL, while porting it to OpenGL 3 and 4, one more like 3.3. So we had a lot of problems with the drivers and a lot of driver bugs with OpenGL. Now, for example, we started having bugs that we didn't have before because the GPU makers just abandoned the OpenGL drivers and they start bit rotting for example. So in the end, we really had to go to Vulkan. When you, for example, we started getting reports from users about performance issues they have and you would look like, for example, you render a scene with 20,000 objects, it was super slow because every object use a different material. But not even a different material, a different geometry. The material was the same for the 20,000. It was really slow. So I was like, what if we try with the same geometry? They were 20,000, they have different geometry, but just a queue. Not many vertices. We tried using the same queue and then it went super flexing fast. So there's cases in OpenGL drivers that the driver does like validations of things under the hood and some combinations of circumstance that you don't really know. They result in slowdowns that are unpredictable. If you're using Linux and Mesa, you can see what a driver does. I'm sure how many of you actually seen any Mesa code. Well, it's interesting. If you want to see how a driver, OpenGL driver works, they do a lot more under the hood that you may expect that a driver does. So with Vulkan, it's kind of like the GPU makers, they went completely to the other side. They said, we're going to make an API that is completely low level. It does no validation for you. You can actually crash your operating system, or more like your windowing system using Vulkan, because it does no validation. You can just do whatever you want. So they went totally the other side. I got a few look-ups of my computer, especially if you run Windows, it kind of crashes on the video restarts. If you're using X11, it just dies. So you have to just restart it yourself or kill it from a terminal. So you start learning the kind of things that crash and you're like, why they didn't validate this, it was so easy. But actually, the philosophy was we won't validate anything. Just do whatever you want. You have the full performance. We give you the gunloader, you just do whatever you want. So it's very interesting actually. So are we on time to start, George? Yeah. It's okay. In two minutes? Yeah. Oh, two more minutes, okay. Then I will tell you a bit more about Vulkan itself. Yes. But don't you have validation layers? Yes, you have validation layers. The validation layers are really useful. But the problem is that if you do something, the validation layer may spit an error. This is something that took me a while to understand because I used to put the validation layers and the validation layers were throw an error every time something goes out. But validation error doesn't do really anything. It just throws an error but passes your command through anyway. So the problem is that I got a lot of crashes even with the validation layer. And it was basically validating it. But yeah, it was printing the error, but then the computer froze. So you have to put a break point on the validation layer when it tells you to write an error and then you can survive it by just catching the error before it freezes. These kind of things are really cool when you work with Vulkan. You start learning it just by making those mistakes, I guess. And then I was getting the actual error from the validation layer, but I didn't know it because it was freezing. So it was like, hey, you know, whatever was printed like that. Of course, it doesn't keep scrolling because it's frozen. So these kind of things are, it's very hardcore. But once you start getting the hang of Vulkan, I think it's beautiful that you get so much low level access to decide how to adapt your rendering code the best as possible as your engine to your code and your engine. Actually, one thing I found is that Golotis is a general purpose game engine. And are we okay? Okay, well, I will just conclude this phrase and start the presentation. So Golotis is a general purpose game engine. And since we need to satisfy the needs of so many games, we need to look for algorithms that are kind of all rounders, you know? Maybe there's algorithms for, I don't know, for cooling the scene or for doing rendering, shallow mapping, different kinds of materials that are better for different kinds of games. If you were making your own triple A super high budget game, you will be fine doing your own stuff. But when you have a general purpose game engine, you need to find all rounders, you know? Algorithms that will work for most of the games and maybe add some tweaking options for different kinds of games. But mostly it should be like good performance overall, but not best performance for specific use case. Maybe some users just take the code and optimize it for a specific use case. But yeah, it's interesting. Vulkan is really good if you want to extract the latest, the smallest drip of performance out of the API if you're making like a custom game made in Vulkan. But for something general purpose, it's a little more complicated. I think they didn't design it so much for it. So there was a lot of trickery that needed to be done, but yeah, it's very interesting. So if you're going to learn Vulkan, just good luck, it's very nice. So I will start with a few facts about Godot, little information about the game engine. A lot of this fully open source, we make an MIT licensed engine. It only uses compatible third party license, so we don't mix proprietary or GPL or anything, just MIT compatible license. And we have it in Hosted on GitHub. One may think like why making an open source game engine? What's the point of doing that? And many people don't know that like of all the software industry revenue, the whole software industry, like everything that writes code and sells it, the whole software industry revenue, out of all that revenue, 25% comes from the video game industry, you know? But when you hear about open source, you don't really hear about games. You just hear about Python, Apache, MongoDB, like things that are my productivity of business services. So there's kind of a big gap in open source in general for whatever is games, I think. So God tries to fit, to fill that 25% missing for the open source software. So we feel our mission is important, even if it's kind of all because you know, and like in, we go to events like GDC and they're like open source, go to an open source event. And we come to open source events, ah, games, go to a game event. So we're kind of like in the middle of something. We believe our mission is super important that we are still in a limbo. So yeah, we are fully open source. We have a really active developer community. This actually is old. We have over a thousand now contributors, like well over a thousand. This has some months and it's already went from 800 to 1,000. We have more core contributors. In fact, the Godot 3.2, we just released Godot 3.2 some days ago, had like almost 400 contributors. So there's a lot of people really interested in making this engine happen and contributing. It's I think the third or fourth, the most fastest growing project in GitHub or something like that. And we have like hundreds of PRs open every month. So it's quite a growing project. We have a very active user community. Again, this is how we just released 3.1. So this probably keeps going. So yeah, we have like a large community on Steam. We publish Godot on Steam. So we know we have a lot of, we now have like over 900 reviews and over one really positive. So yeah, if you go to Twitter, if you go to Reddit, if you go to Discord, if you go to IRC, Facebook, you will find really large Godot communities. Really helpful. We try to make sure that the tone is always nice and friendly. So, well, let's go about, let's start and with the facts go with Vulkan. So Godot used to be a proprietary game engine. Ariel Mansour and I had our company for a long time. At some point we open source the game engine, like in 2014 and it started growing. Back then it was mostly mean for mobile. It had 3D rendering, but it wasn't very good. It was just OpenGL 2. When Godot 3 came out, we ported to OpenGL 3.3. So we could use newer features and use OpenGL ES3. At the time, it was a few years ago, it seemed like a really good idea. But the truth is that OpenGL mobile is broken. The drivers are all broken. Mobile devices don't get updated. So it was a pain. And then yeah, we saw that OpenGL when Vulkan came out, they said, yeah, this is going to be an alternative. We're going to continue working on OpenGL. Lies. It's abandoned. Nobody cares anymore about OpenGL. It's dead. So one thing about the OpenGL is that the API design does not really map very well to modern hardware. It's not really when you learn Vulkan, you realize what the hardware actually does. And you understand that OpenGL doesn't really, like I will give you a very small examples and so many of you actually are interested in rendering. You know, in OpenGL, you can like set the vertex buffer. You can set the textures in use. You can set a lot of rustering operations like the winding of the triangles or if you draw lines or if you write quads or quads in those anymore, triangles, lines, points. You can change a lot of things and then you call it our function. When did you know that when you do all these things, changing the state, OpenGL actually is patching the shader. It actually is modifying the code of the shader. It has a shader in memory that you bind the shader. You change all these things and it binds the shader. If you change like the shader, it needs to repatch the shader with all the changes you have done. So there's a lot of code, invisible code inside of OpenGL that you don't know that it's patching the shader and doing a lot of work every time you change those status. The APS are like Vulkan which are called, it's not entirely stateless, but it's mostly pipeline-based. It's called pipeline-based. You just create one object with all the states and if you want to change the stage, you just create more of those objects. The pipeline has the shader and all the states you set in OpenGL like the vertex buffer format and the geometry and the antialiasing everything just in one object. So the thing is when you set a pipeline to draw, it just sets everything at once and it's super, super fast. This is really fast. So Vulkan forces you to just get your data together properly and when you set everything together, it's just much faster. So these kinds of things make it much more optimal to draw a large amount of objects. When we started porting the engine to Vulkan, the first thing we noticed is there's a huge increment in performance even in the 2D engine because we just call GL draw arrays like every time we draw a primitive and just using Vulkan, even if you're doing the same amount like, not the same but similar amount of calls, the performance was like whoa, it was impressive how much it, so when Vulkan is more modern than OpenGL, it's more up to date. For example, if you want to use ray tracing extensions, now there's going to be, it's only NVIDIA but soon there's going to be like an official RTX implementation for Vulkan. So this is not any longer in OpenGL because as I said, OpenGL is there. So all the new extensions like ACR rendering a lot of these things are just coming out for Vulkan. OpenGL is just ignored nowadays. It kind of, this sounds a bit weird but it really works as an entry barrier because we have the problem that for example, all the rendering we thought that we were going to making OpenGL 3.3 compatible which dates back to DirectX 10 like 2008, 2009, I think around that. So you can ruin all the high-end Godot 3 renders in really old hardware. And truth is that that doesn't work in that hardware because the hardware has too little video memory, too little limitations, it's low. So with Vulkan we can just make sure that if you have old hardware, you're not going to ruin it because it's just designed for modern stuff and we don't have users complaining, I got all this low because yes, you run it in 10 years old hardware and you're putting all the pretty effects and of course it's going to this low. So now it's a nice entry barrier which means that we can focus on optimizations and new features and everything and people that uses Vulkan will be able to run it and if you have a computer that does not support Vulkan, you're going to be using the OpenGL renderer which is the compatibility render which is designed for hardware so you will be fine anyway. I mean less confusion for the users is good for us. One of the new things we added to Godot is creating a new layer which is rendering device. Now, this is very interesting. The rendering APS actually, even if Vulkan looks really, really complicated because it is, you can actually abstract to a higher level API really easily and make something really simple because now we only have like pretty much the textures, the buffers, the frame buffers and even some APS like metal don't even have that. You have the shaders, the pipelines and then the render release and that's it, there's not so much. Actually, amazingly, even if in some aspects Vulkan is really complicated, a lot of complexity that came from the time of OpenGL has been lifted because now a lot of things are more general purpose than they used to be. So in Godot 4, we are going to have the resource error which is the main abstraction for rendering. It's the entry barrier for anything that has to do with rendering. We're going to have two rasterizers. One is going to use every rendering device and render device is what abstracts Vulkan. We can make it abstract now metal or DirectX 12 or there's some people porting it to PlayStation. We can't do it because we're open source but they can use to port, it's much easier to port rendering device to Vulkan. And then we have a rasterizer that is GLDS2. Maybe we will add some GLDS3 functionality and this uses OpenGL ES. So we have a completely different, I mean, this will serve abstract the API but then you're going to have a different, completely different backend depending on modern stuff or compatibility stuff. So if this is transparent to user, you just switch if you want to use OpenGL or Vulkan and everything just works. Whatever is done supporting OpenGL doesn't appear, it's just hidden. So well, the other thing that users requested a lot and a lot that you couldn't do before that you will be able to do a lot for is that you will be able to access from your scripting language or whatever you want like C++ to rendering device which is the Vulkan abstract, like the rendering abstraction. So if you actually want to do like more advanced custom rendering on the engine, now you will be able to because you will be able to insert your own code during the rendering loop. That hopefully will be very nice. It was one of the most requested features. And yeah, it's eventually portable to more APIs. There's like porting, if you wanted to port Godot 3 to the PlayStation you have to write the entire Rasterizer which is really huge. For Godot 4, you just port like rendering device and that's it, it's much smaller. So another thing we're going to have in Godot 4, we decided it was the best way to go is, at first we tried to do a rendering, Vulkan rendering code that supports both mobile and desktop. But as we started working on this, we realized that mobile and desktop are really completely different architectures. It's not even worth trying to use the same code for both. So Godot is going to have a high and low end Vulkan renderers. This is separate from the OpenGL legacy renderer. So the high end will be just for desktop. We're just going to use like, for example, let me give you a few examples. On desktop, Vulkan has something called the scriptor sets which is the amount of like you could call it uniforms and other things that you combine to shaders in groups. Like on desktop, I think the limit is 16 but the mobile is four. So when you have more, you can optimize more, a lot of things. So we were being restricted to fortress from mobile. Then at some point, it's not worth it. Let's just make the high end use this. For example, on desktop, you can have something called indirect texturing, indirect textural resting. You can put all your textures in a big array and then you use an integer to address the textures. This works fine on desktop. It has very little cost. On mobile, you just come to it. So, and for example, on mobile, you still have really low texture limits. I think you can, some architectures like ARM, my lead drivers, don't let you have more than 16 textures in total or samplers. Actually, not even sampler, just textures. You can't have more than 16 textures per shader. While on desktop, this is infinite. You can have all the textures you want. Maybe the samplers are limited because it's a hardware limitation but the texture you can have as many as you want. So the problem is that the difference between what you can do on mobile and what you can do on desktop right now is so big. It's so, so big. It doesn't really make sense to make something that works for both. You're going to be crippling the desktop just to make mobile work. So we're going to have high and low under parameter. I think for Vulkan, it makes the most sense. Also, for mobile, there's something you can do which is called, it's a Vulkan feature which is called subpasses. Have you heard of subpasses? Well, subpasses are something you can use on mobile due to how mobile chipset works. Like, mobile have a lot of... When you have something rendered, when you render on desktop, it's just brute force pretty much. It just draws all the triangles to throw one after the other. On mobile, the screen is divided like in tiles, in cells. And every cell has a list of the triangles that touch this cell when you render. And then at the end, it drusters all the triangles. They do it this way so they can have like more parallelism. And actually, it's like even if you render forward, it's always deferred because it only shades the last pixel that was drawn after. It's like a mini deferred rendering a tile. So because they work like that, maybe you want to have many passes. Like for example, you do a deferred renderer and the first pass, you want to render all the materials and the second pass, you want to do the shading. So if you have subpasses, you're telling the mobile driver that after this pass, I'm going to the shading. So if a tile is done doing the rendering of the triangles, you can go to the next pass while the other tiles didn't finish. So it's so different. Mobile and desktop are really different. So you should probably, if you're going to use Vulkan, Vulkan will give you such low level access to these kinds of things that it's a waste to try to make something that works on both. Just make one that works on mobile. Just one make one that works for desktop. That's what we ended up doing with Godot. So the idea is that they are still both compatible and you will be able to switch between the high and low end renders at any time. Well, as I was saying before, Vulkan is designed for, I explained to you, it's just designed for low bottlenecks. Low amount of bottlenecks, just very low driver overhead. You just can, it's amazing. You just do a lot of draw calls. You can have like, I don't know, 50,000 draw calls in Vulkan and it uses so little CPU compared to Open Shield that it's amazing. So the first thing, as I was telling before that we saw when moving from OpenGL to Vulkan was a massive improvement of performance when just throwing the large amount of objects to deal or it's just a massive improvement. One thing that people may get confused is that, yes, Vulkan is faster, but calling the API is mostly faster. Like if you have a very simple scene, like just one room with a few things that are furniture and really complex shader, it's going to run the same in OpenGL and in Vulkan because the shader performance is the same in both. That doesn't change. But if you have a really huge scenario like a city or I don't know, underwater or something really big that you can see really far away, yeah, Vulkan will make a big difference there. Like for really large stuff or something that has a lot of small objects that's going to make just a huge difference. So, yeah, that's kind of the same. For 2D, the performance improved hugely. It's impressive how fast it is. For 2D, it's very difficult. Like when you work on 2D on OpenGL, you usually want to implement things like batching because there's a lot of, you just put everything in an array and then send it to render because the cost of the draw call itself is kind of slow in mobile, especially in mobile. But with Vulkan, it's like since there's no validation between the draw calls or anything, you can just throw the commands and it doesn't seem to really have any performance impact. That's really impressive. How well the drivers are optimized for a very high amount of time. If you want to even optimize it better, what you can do is simply like run, like the render release, you can separate it. You have the, imagine you want to render 20,000 objects. You can run threads that each, like you want to run eight threads. Each one renders a chunk of the objects in a separate part of the list and then if you put them together and send this kind of organization, that's great. So this is really important. It's a very big advantage of Vulkan but it's very often overlooked. Is that OpenGL is very buggy because it's very complex. If you look at an OpenGL driver, it's huge. It's really, really big. You can even, if you look in Google, you can read horror stories about people working at NVIDIA or AMD, working on drivers, like for example, they were saying, I think at the time OpenGL 4 came out, I think I remember reading that, reading that AMD decided to rewrite their OpenGL driver. They started, because the old one was too slow and they started, they first rewrote it and it was very fast but it was very incompatible, it didn't work with a lot of games. So they had to start adding patches to make it work better with different games. By the time they ended up adding all the patches to make it work like the old driver, it was slower than the old driver. Because, and this is AMD, I mean it's the top company that make these kind of things. So OpenGL is very complex. It's very difficult to optimize because you need to optimize the way you think games are going to use it but then games may use it a different way. It's a typical software design problem. If you try to make something super flexible, you're going to end with something complicated and then it's not going to be useful because users don't really want to use it that way. They still want to use it a different. So with Wolfgang they were like, we suck, we can't make these kind of complex APIs. But just let's make something really low level and let the users do whatever they want. And because of that, the APIs are so simple, they map so directly to the hardware that they are very less prone to have bugs because it's just much smaller. If you look at a Wolfgang driver, like the Mesa drivers, it's just much smaller. It just maps much more directly to the hardware. This is very, they're very interesting. I think this was a really good decision. At first, when you start learning Wolfgang, you're like, what, this is so complicated, why they made it so complicated? But in the end you realize that what you write is going to be a lot more effort but it's going to work much better and it's going to be like less baggy when you run it on different hardware. Which isn't to say that you just, if you have NVIDIA or AMD, for example, you still need to try everywhere because there are things like barriers. For example, Wolfgang has something called barriers, which is used to synchronization points between different kinds of tasks. Like for example, compute, you do compute and then you want to use what you did for compute for rendering and use it as a texture. You need a barrier both for waiting until the compute is done and for converting the resulting image to something readable by what is rendering. You need this kind of barriers which you need to put everywhere in Wolfgang. Wolfgang barriers are really complex. They have a lot of options and not all the hardware implements all the barriers, you know? I think NVIDIA implements them like more cores, AMD is more fine-grained. So an Intel just like doesn't care about anything. I think it's like, my experiments with Intel is whatever you do, even if you forget all the barriers, it still works. So it's really weird. So Intel is just weird, but the thing is because of this, I had problems like getting, you get something to work, like even in the same AMD drivers, I got things to work in AMD in Mesa but didn't work in the official AMD driver for Linux and then you can swap it and then it works in one and doesn't work. Then you go to NVIDIA and just doesn't work. On Intel, it always works. It's amazing because it's just surprising. I don't think they even support barriers in Intel, but that's what it was saying. Less complexity is less points of value. You still have to test the hardware, but let's run two bucks. One problem we have with OpenGL is that OpenGL doesn't have a standard way of catching the shaders. So our users often complain that an object appears on screen that was never rendered. And even if you pre-compile the shader reform, it still has like a delay because the driver waits until everything is ready to render to just actually compile the shader. So with OpenGL, we have a lot of stalls all the time. So users have to resort to making like a loading screen that actually is a plane that has all the objects that need to be rendered with all the materials, but you don't see them. They are behind the wall. So that actually forces it to actually compile all the materials before you go into the game. This is very, very typical with OpenGL. With Vulkan, what they added was something called Spear-V. Spear-V is like a shader bytecode. You compile GLSL. You can actually compile GLSL, which is very popular because it's the Microsoft one. People that do rendering prefer direct text, I don't. But GLSL is very popular. I don't like it, honestly. I think GLSL is nicer, but well, anyway. You can compile to Spear-V from either of the languages on Vulkan. And the interesting thing is that Spear-V is not really a shader bytecode that gets executed by the GPU. It's more like a middle. If you have seen compiler theory, it's like the SSA form of the shader. It's kind of pre-optimized up to a point, but it's still not a bytecode. I mean, it's not something you can put in a virtual machine on a GPU and ruin it more like it. So the interesting thing is that it is faster to go from Spear-V to the actual GPU bytecode that going from GLSL. It has also the problem with OpenGL, for example, one problem we have is that if you have to list all the GLSL compilers, you have, for example, the AMD one, the NVIDIA one, the Intel one, the Web browser one because of WebGL, you have the mobile ones like, for example, the Mali one, the Qualcomm one, the Tegra one, the Apple one because Apple now no longer uses PowerVR. They make it on GPU. So now we have the Apple compiler for GLSL. So there's like 10 compilers for GLSL. One of them is always going to break because parsing text is much more difficult than in theory it isn't, but in practice it is. Parsing text is more or prone than parsing just a bytecode that has very specific instructions. So Spear-V has the advantage that once it compiles to Spear-V, you know it's going to work. And it's faster to compile from Spear-V to to actually the bytecode. The thing is the following. The only thing you can actually send from one, from, imagine you want to distribute your game. You can distribute Spear-V shaders, but you can't distribute pipeline objects. You can actually get the binary of the pipeline object because the pipeline object, I mean, you have shader code, you compile it, you get Spear-V. Spear-V, you combine with all the rasterizer data, like which kind of triangles, which kind of frame buffer, which perform at everything. All these, you get the pipeline state object. The pipeline is platform dependent. It's even driver dependent. You can't even like, if you make a game and distribute it for AMD, they may change the driver and it's not going to work anymore. So you need to, you can use to cache it locally, the pipeline and your computer. You have to cache it even saving the driver version. There's a few articles about that. This is pretty interesting. Because it's very easy to break something caching a pipeline state. But the thing is that even that, compiling Spear-V to pipeline state is really fast, compared to just all the whole thing. In fact, I don't want to go sidetrack too much, but there's WebGPU coming. You probably heard of WebGPU. There's a big discussion now. You have Apple on one side. You have Google, Microsoft and Mozilla on the other side because Apple wants to use something called WHLSL, which is a text format. And all the others want to use a Spear-V for WebGPU. It's been years and they haven't agreed. Apple really doesn't want to have anything to do with Kronos. They are even deprecated of a GL. They are like, say, away Kronos. And all the other people are, no, Spear-V is amazing. Why not use Spear-V? We have a lot of tooling for Spear-V, which is amazing. We can convert it within a lot of different languages. So they are completely, I don't think they will ever agree. So we'll probably see WebGPU with Spear-V for these browsers and with WHLSL for Safari. That's probably what's going to end up happening at this point because Apple just doesn't want to consider anything. So I actually went into arguments with people from Apple because they really defend the stance on WHLSL and my experience with Godot on WebGPU, but you're on WebGL, compiling a GLSL shader. It takes a long time for WebGL because it's so many validations for security. So just using bytecode, it's probably still dangerous, but it's faster. So another interesting thing about Vulkan is threads. When you hear about threads on Vulkan, the only thing that probably comes to mind is what you heard about the secondary command buffers. You probably, if you are going to read about Vulkan, you can use secondary command buffers. You create each one in a thread and then you put all of them together and then send it to the rendering. It's faster. Yeah, it is faster, but there's many things that are really cool that you can do with Vulkan. Like the first thing that, since it takes Spear-V and not GLSL, and even if it takes Spear-V on whatever you want, you can just compile shaders on threads and then you feed the Spear-V. It's super efficient. You can actually create many multiple render lists, not just one with multiple secondary command buffers. You can create multiple render lists at the same time, which is also amazing. Like imagine you're rendering shadow mapping. I need to render directional light shadow mapping. You need the four splits that are typical to this. You can just create one render list for each at the same time, as an example. You can do a lot of really amazing optimizations in Vulkan with that. The other thing that is really amazing is all the queues with asynchronous texture and buffer transfers. When you start learning Vulkan, one of the first things you see, the first is Vulkan device, and then you see the Vulkan queues. The Vulkan queues are really interesting. It's like by definition, one of them has to be rendering, compute, and transfer, and then it has to have one transfer one and one compute one, I think. I think it was something like that. The interesting thing is that for example, imagine you're running the game, but you want to load a texture asynchronously. What you do is you just use the transfer queue for that. You just allocate the texture because texture allocation is completely independent of what you are doing. So you just allocate the memory for a texture, and then you use the transfer queue to send the texture while you're still doing your normal rendering in another thread, so that's super, super efficient. I really like that. And you can do the same with buffers if you want to upload geometry, textures, everything. You use the transfer queues for this. Or even if you want to do things on a thread for compute, you can run computes at the same time as. So all these kinds of things are really, really nice. I actually really enjoy the way it works. It's super complicated, but once you understand exactly what it is, it's really enjoyable. And you can make a lot of really nice optimizations. So another interesting thing about this is when you learn, if you come from direct text 12, or direct text, and you go to Vulkan, it's going to appear really complicated because Vulkan forces you a lot of things that are normally not necessary for desktop because these things are actually more optimal on mobile. The second that I already talked to you about the render passes, you can just break the rendering render passes so the tiles in the mobile GPU can do work in parallel, even in separate passes, otherwise it has to finish and then go to the next one. This is more optimal. The image barriers are interesting, like for example, you can use something as a render buffer and then you want to use it as a texture and you want to do a lot of work like that. Since you have to specify all the conversions between what you're using the image for, you can actually make a lot of interesting optimizations. So yeah, it's interesting because it kind of sucks if you're going for only desktop, but if you want to optimize for mobile, there's a lot of opportunities there that are really interesting. So the last thing is that since we used OpenGL, we didn't have compute. There was OpenCL, but it was never well supported because NVIDIA kind of sabotaged it. There's a lot of, how you call it, like a lot of internal politics rendering, it's amazing. So NVIDIA sabotaged OpenCL so when we ended up doing it, and yeah, Apple proposed it and then abandoned it, it's so weird. So the interesting thing about compute is in Vulkan is that you just use it with GLSL. It may seem a bit weird because people use compute just see OpenCL or see CUDA, but GLSL is pretty nice for compute. I mean, you can still do things normally and it's pretty like to the point, you know? A lot of optimizations can be done, like for example, normally in OpenGL, if you want to do a full screen effect, you draw like a quad, or some people even draw a triangle so it doesn't render the middle line, which supposedly it's faster. So well, there's a lot of things, but in compute you just run the compute directly, you don't have to go through them. Drawing the geometry, it just does compute so it's super interesting. And we are actually exposing compute to the user because if you see a lot of games, it's very interesting. Compute now is so complex that you can use it for gameplay. If you want to make a game that has like 10,000 enemies, you can totally destroy your CPU trying to do this or you just can use compute, and compute works fantastic. An interesting thing is that in Vulkan, you can have more than one device. Vulkan has the VK device, you can have more than one VK device. So you can just have your device for rendering and you can have your device for doing game logic, which is really interesting, especially on desktop, but you can do really complex game logic. Internally it's going to still send one thing at a time, supposedly. I don't really know the implementation details, but you can still do it and it works really well. You can optimize your games a lot with compute now. I think this is not something that is used much on game development, but I see in compute a huge opportunity to optimize lots of types of gameplay. So this is just a few goals related things because the talk is about Godot. One thing that we are doing in the new rendering Godot is that this is a kind of usability thing. You're making an engine for people to use, so you give them an option to, you give them, in effect you give them an option. You want to look ugly or pretty, like quality, low on height. User will always look high because it looks better, like why not? And then they go like, wow, this is really slow, this engine sucks. So we learned that mistake, so what we really know is moving on. Everything related to the quality and performance, we went to the general settings of the engine, and we put it like, this is low, this is fast. Hoping that this will be a bit more obvious for the user that you're making these mistakes. And also, this is more like a way that Godot works in Godot. When you have project settings, you don't have overrides. Like for example, if it's going to run on mobile, you can override the settings for mobile. And having the quality settings on the project settings, allow it for example, if you want, this is a depth of field setting, you know? Box is super fast, but it looks like a box, it's kind of a weird depth of field effect, but it's super fast. If you use it for something small, it's okay. And circle, it's super slow, but it looks amazing. It's only for like, ultimate dedicated GPUs. So what you can do is, you can put an override, depth of field shape. If you are targeting mobile, you can override this and go from circle to box. And you can have, for example, I'm right for low end high end renderers. So when the high end can use circle, the low end can use hexagon, for example. So this is pretty cool. There are new things we are doing. And lastly, this is the last item. One thing that, we went from OpenGL to Vulkan, but we never had heritage rendering. So we always kept all the interpolation, the mid-maps and everything in the texture, which is what happens in OpenGL in Godot 3. But now textures and samples are separate. And it's really cool because if you separate them, you can have as many textures as you want, just using the sample. But now users will have to move this, like for example, now we have this in each node for 2D, you have to configure if you want, which kind of filtering you want. And if you make materials, you have to configure the filtering on the material, no longer in the texture. That's the last change we have to do. This, again, improves performance and makes sure you have unlimited textures, but the way you work on it is just a bit different. That's all. So well, this concludes the talk. If you have any questions or want to know more, sorry, know more about Godot or Vulkan or anything and here to answer questions. You were first, sorry. Since you mentioned WebGPU, what are your plans for it? Ah, that's a good question. It will be interesting to make a rendering device for WebGPU because it's very interesting. I don't think there is any Vulkan over WebGPU. Could be easy to at least test it if we had a Vulkan wrapper for WebGPU. But we're probably going to have to write a backend for it. That would hopefully be very interesting. I don't see that it's going to be dispute between Apple and the rest of the world. It doesn't seem like it's going to get solved. So I can imagine that the Spirby tools, guys, are going to make something to convert Spirby back to a text shader so it runs on Apple. So yeah, that's kind of what I think about it. I guess it's going to work eventually. It's going to be a bit messy on Safari, probably. But yeah, they did implement it eventually. Probably for the dot 4.1, not for the dot 4, which more or less is stable now. But yeah, that's true. And you wanted to ask something? Is there any reason for Apple to want their WUN? I have no clue. Ah, yeah, sorry. He asked if there is any reason for Apple to deny. I really don't know what's going on. It's internal politics between the companies. For us, people outside doesn't make any sense. I think Apple exited Kronos at some point because Apple was part of the Vulkan working group up to some point, and then they exited Kronos, and they have nothing to do with Kronos anymore. Maybe that has anything to it, but what GPU is actually W3C is not Kronos, but Spirby is Kronos. So maybe because they don't want to have anything with Kronos, I really don't know. It's just speculation, I don't know what that's. Also, does iOS support Vulkan? Oh. If so, it has a Spirby support. No, iOS and Mac OS don't support Vulkan. They support Metal. The thing is that it's not really a secret if you dig into it, but Apple knows that nobody really cares about Metal because the gamers don't really use Metal. So what they did recently is just add more features to Metal. So the Molten BK, which is the wrapper of the Vulkan or Metal, just works better. They secretly did it, let's say. Apple is like, you know, it's a very secrecy company. You won't see them at any event. They don't have the public engineers. It's like, so in the end, it works really well. We may eventually put rendering device to Metal if we see that there is a benefit and improvement in performance, because why not otherwise? But in the meantime, right now, it's working with Molten BK. It works really well. I run it on Mac OS and it just works, so it's OK. Any other questions? Well, let's go right to left. Sorry, you started. When you talked in the beginning not about rendering, but about Godot, you mentioned how the development is going and everything, but how about users? Again, it's using your engine, how does community look from this direction? And also, because now we're talking about devices, Mac, iOS, everything, do you know where Godot is used more? That's kind of complicated. Well, the question is more about the community, if I understand what they use it more and what they are expecting. The biggest complaint, the problem is Godot started as a 2D engine. Mostly, it has to be with almost nobody use it. So nobody even bothered to use it and report back. When we rewrote it in OpenGL 3.3, more people started to use it and they had a lot of complaining that it was low, that they needed pictures and a lot of things. So at the same time, we were going to continue working in OpenGL because it just didn't work in a lot of levels. So we had to set the rendering stone for two years, fix a lot of the bugs, because 3.0 was a very big release. And now we are porting everything to Vulkan and trying to satisfy all the demands from users about improved performance, more features, more model and features, more portability, working on more platforms. So right now, the direction is trying to cope with all the user demand. It's like the engine is slowly going from mostly to the engine to 3D engine, too. But yeah, it takes a while until everything. I think that Vulkan 1 is going to be really cool. I mean, it's going to be almost on the same level as using the high end rendering unity or Unreal. So it's going to be more or less in that same level, I hope. Or at least it will be closing out that everything else that is missing can be added without that much effort. So yeah, that's the situation. Wait, we weren't going yet. So the Vulkan branch is now merged into master. Does that mean that the? Next week's probably. Or in the next week's probably. Yeah. So does that mean that it is fully integrated? Oh no, not close. It's going to be broken for a wide master. I mean, it's going to, you shouldn't put your game to Vulkan yet. Some people, some really, some people that love living on the edge are actually publishing their game on the Vulkan branch. But you should probably not do it. Probably by the middle of the year, the Vulkan branch will be complete, like May, June, or July. And then we will focus on stabilization. So release will probably be good for second half of the year. It will be very usable probably by the middle of the year. It will be able to use it fine. It's just going to have bugs. Just for developing, it's OK for releasing maybe not so much. And when we can actually release, it will be a few months later. So that's kind of the roadmap. But yeah, it's going to be totally broken in a week. Sorry, you out? Is it going to be possible to port games from 3.2 to 4? Yeah, porting games from 3.2 to 4 should be much easier than it was going from 2 to 3, which completely broke a lot of things. Most of the data remains compatible. You should be able to port your project. Maybe the scripts, the biggest change may probably be that you have to adjust the texture options in the material now, because they will be gone from the texture. And the fact that GD Script is going to suffer compatibility breaking changes, we will not be so terrible and we'll be really good. He's doing them, not me. But it will be really, really much better. We actually may make a script. We can just parse the old ones and convert to new ones probably. So probably an export tool will be needed. But compared to the pain that she knows, it's porting your game from 2 to 3. This will be a lot less painful. So yeah, that's it. We have time for more questions or we are? OK. So go to port, what is it going to use on desktop windows platforms that don't support Vulkan? Do Windows desktop platforms exist that don't support Vulkan? Oh, you mean the older computers that have a GPU that don't run Vulkan? Yes. No, that's going to keep using OpenGL. The thing is that those are all, I mean, what limits you in those platforms is not so much the feature set, but the resources and the performance. If you make a game with Vulkan in mind, you're thinking of the GPUs that have maybe four gigabytes of video memory are really fast. The older devices that don't support Vulkan, which is kind of like the DirectX 10 level devices, they usually only have like 200 megabytes of video memory. They are usually just lower. They don't have usually as much, maybe a high-end one has a bit more, but in average, they are not as powerful and they will still not be able to run the game. So if you want to make a, for 2D games, it's fine because they will look the same. It's just going to work. I mean, it's not going to have a lot of difference. But for 3D games, if you want to make something that uses all the highest and rendering features on those computers, it's just not going to work. I mean, it's going to work, but it's going to be slower. So you should probably use something like, instead of Vulkan tracing for global illumination, you may want to use like mapping, which is faster if you want to run on that device. But yeah, that's kind of the goal. So we have more time, yes? Any other questions? So, yes. About the rendering, the rendering backends. I don't know if Gallup has a PBR pipeline. Yeah, it is PBR. Well, if you want to implement new rendering techniques, do you have to implement it for each backend, say for the low-end renderer and the high-end renderer for Vulkan or PBR? No, that should be the same. It should work a lot of times. So one thing we discussed a lot, which may be interesting for you if you are into rendering, is that Gallup is meant to be an easy to use game engine. So one thing we are not implementing as an example is temporality aliasing, because it means you need to let users that make shedders understand that they need to get a hold of motion vectors and they're super difficult. I mean, it's already difficult for really big games that have a lot of budget. So expecting our users to be able to maintain motion vectors is probably not worth it. So what you're going to do is find alternate ways to do the same, like for example, the high-end rendering that Gallup is going to use forward rendering with cluster lighting, which is kind of trendy now. It's like, I think what most new games use now, like the new DOOM, for example, uses that, and I think many new games are moving to that. So maybe then you have the problem that some things have more aliasing that are not just the geometry. So we are using other techniques to reduce the aliasing and still have a very stable image as an example. The lower-end rendering may use different techniques, maybe just forward single pass or soft, or maybe on the older devices will be forward, but multi-pass, which is better for really old stuff. But the shader you write, Gallup gives you like a GLSL to write your code, but it's not the GLSL from OpenGL. It's like a managed GSL that is very easy to use, has auto-completion, has a lot of outputs already assigned for you to write. So you write that code, and then that gets compiled for the high-end, for the medium-end, for the low-end, and you don't have to do anything. And if you want to implement custom lightning, you can write light shaders, and for example you have the vertex shader, the fragment shader, and the light shader, if you want the code that runs for each light. So if you want to read something custom, you do that, and then that's going to be compiled as different, the different rendering techniques will still run your shader in different ways and you just write it once and it works. Any more questions, or are we okay? Yes? Are you running validation arena? Running? Vulcan validation, do you have any errors? The Vulcan validation layers. Ah, yes, yes, well, to debug it's always, we always run Vulcan validation. So I mean, do you see errors in your work of the port? I think there's nothing now, but who knows? I mean, I usually develop on NVIDIA and test on MD and Intel, but right now it's not meant to be stable, so there's probably some errors if you run in different, when it's stable it's not going to have any errors of course, but right now, yeah, it's typical that you use something that works in one platform and then the other uses, also NVIDIA has their own validation layers besides the LunarG, so usually it throws different errors. NVIDIA once are usually like, I don't care about that, so it just turned them off. But it was the same with OpenGL, they just give you too much information usually, they assume too much about what you're doing, but yeah, the idea is that you can anyway turn it on and run it and we're going to have one of our contributors is setting up a farm that if you have commits and PRs and everything, it's going to run benchmarks and things and it's going to like capture it, there is a regression in performance, regression in quality, if there are validation layer errors that appeared. So to avoid these kind of cases, we are trying to use CI for these kind of things. We actually got a really nice donation from AMD to the GPUs and CPUs to make this little farm. So it's going to be pretty good once it's working. Yes? Is there any key differences between WebGPU and Vulkan or is it like WebGL? WebGPU is more like metal because Apple proposed it. So yeah, it's so funny because, sorry, I shouldn't say that, but they proposed WebGPU with WHLSL and everybody was like, well, let's be in good terms with Apple again. We could have done Vulkan for the web, but let's do WebGPU because it's okay, metal is easier to validate than Vulkan and they went with Apple and they told Apple, yeah, but we'd like to use Spirvee, not really. And Apple was like, well, let's discuss it. Like four years later, Apple is like, no way, not touching Spirvee. So yeah, that's what's happening. Sorry to interject. No? Tomorrow's going to be more information. I will be, you're going to be more information? Really? Yes. You're all witnesses to this. Don't forget. Okay. So yeah, I hope, actually, I hope this is solved at some point because it's really annoying. To be honest, it's been WebGL sucks pretty much. It has too many problems. It's okay for simple things, but porting a game engine to WebGL has too many shortcomings, especially shader compilation is just a big, big pain. So I hope if this situation is resolved at some point, that would be fantastic. I really hope this gets solved. So I will assist your presentation. Any more questions or are we okay? Okay, thanks everybody. It's been a pleasure. Thank you.