Benefits of porting Godot Engine to Vulkan List of benefits observed from porting Godot Engine to V…

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 uh i can tailor it a bit better for your needs uh how many of you guys actually like or are enthusiasts or go about like rendering you guys if you can raise your hand how many like rendering okay that's quite a good amount oh okay how many of you that do rendering actually are interested in bulking okay that's a good amount how many actually understand vulcan uh not so many okay okay then i won't go into that many super low level technical details of woolcon because it can be uh we tried this a few months ago and it didn't end very well because uh uh lucan is like a bit difficult uh takes a while so we still have a bit more time i guess [Music] five minutes okay so that's okay well nice to see so many interests so much interest in rendering yes when it's worried that today you see a lot of game engines and like including a lot and that people wouldn't be interested anymore about rendering but nice to see regulars actually like it so [Music] okay how many here have you scolot oh nice good to see so many other juicers it keeps growing every year that's nice nice to know that you're here and not in the global game jam at least that's it's something so okay well the talk will be mostly about uh the kind of things that we take advantage of using woocomm i think mumbulkan came out a few years ago it wasn't very clear what it was for because you had opengl it worked it there was directx 11 and director x12 was still kind of like something new and nobody really quite got what it was about uh when we saw vulcan we were like what is this for so we took a while actually to get the engine to be ported to we'll come it's still in in the process uh we learned a few bad things about opengl while porting it open gl three and four one more like 3.3 so we had a lot of problem with the drivers and a lot of driver backs 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 to go to glucan and 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 uh because every object uses a different material like but not even a different material a different geometry the material was the same for 20 000. i was really slow so i was like what if we try with the same geometry like they were 20 000 they have different geometry but just a cube like you know not many vertices uh we tried using the same tube and then it went super blexing fast so there's cases in opengl drivers like that you the driver does like validation some things under the house and some combinations of circumstances that you don't really know and they result in slowdowns that are kind of unpredictable uh if you're like using linux and mesa you can kind of see what the driver does i'm not sure have any of you actually seen any mesa code well it's it's interesting uh if you want to see how a driver over gl driver works uh they do a lot of a lot more under the hood that you may expect that a driver does so with vulcan it's kind of like the the gpu makers they went like 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 vulcan because it doesn't know validation you can just do whatever you want so they went totally the other side and i got a few low caps of my computer especially if you run windows it's 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 uh we give you the gun loaded you just do whatever you want uh so it's very interesting actually so well are we on time to start church yeah two minutes okay uh in two minutes yeah well two more minutes okay then uh i will tell you a bit more about bulgaria yes um validation layers yes you have validation layers the validation layers are actually 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 doesn't do really anything it just throws an error but passes your command through any way so the problem is that i got a lot of crashes even with a validation layer it was why isn't it validating it but yeah it was printing the error but then the computer froze so you you have to put a breakpoint on the validation layer when it tells you to write an error and then you you can survive it by just like catching the error before it freezes like this kind of things are really cool when you work with with vulcan uh you start learning it like uh just by making those mistakes i guess uh 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 nowhere over splintered like yeah you 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 vulcan i think it's beautiful that you get so so much low level access to decide how to adapt your rendering code the best as possible as your engine uh to your code on your engine actually one thing i i found is that glock is a general purpose game engine and we're okay okay well i will just conclude this phrase and start the presentation so i go to 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 shadow mapping uh different kinds of materials there are better for different kind of games if you were making your own aaa 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 kind 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 uh it's interesting vulcan is really good if you want to like extract the latest the the smallest drip of performance out of of the api if you're making like a custom game made in bootcamp uh but for something general purpose it's a little more complicated i think they they didn't design it so much for it uh so there was a lot of trigger that needed to be done but yeah it's very interesting so if you're going to learn bull candles just good luck it's very nice so i will start with a few facts about kodot little information about the game the game engine although this fully open source we make a mit licensed engine it only uses a compatible third party license so we don't mix proprietary or gpl or anything just mit compatible license and we have it on hosted on github uh one main thing like why making an open source game engine uh what's what's the point of doing that and many people don't know that like of all the software industry revenue uh 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 a 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 feel that 25 missing for the open source software so we we feel our mission is important ever even if uh it's kind of fun because you know in 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 our games go to a game event like so we're kind of like in the middle of something we believe our mission is super important but we are still in a limbo so well yeah we are fully open source uh 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 one from eight hundred two thousand uh we have more country core contributors in fact they got a 3.2 we just released color 3.2 uh some days ago i had like almost 400 contributors so there's a lot of people really interested in in making this engine happen and contributing it's i think the third or fourth most fastest growing project in github or something like that and we have like hundreds of prs opened 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 uh so yeah we we have like a large community on steam we publish golothon's team uh so we know uh we have a lot of we now have like over 900 reviews in our repository overwhelmingly positive uh so yeah if you go to twitter if you want to read it if you go to discord if you go to irc uh facebook you will find really large code communities really helpful we try to make sure that the tone is always nice and friendly so well let's go about uh let's start end with the facts go with vulcan so uh godot used to be a proprietary game engine uh ariel mansour and i had our company for a long time uh 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 open gl2 when the three came out uh we ported to opengl 3.3 so we could use newer features and use opengl es3 with at the time it was a few years ago it was seemed like a really good idea uh but the truth is that opengl mobile is broken the drivers are all broken uh mobile devices don't get updated so it's uh it was a pain uh and then yeah we saw that opengl when vulcan came out they said yeah this is going to be an alternative we're going to continue working on opengl lies it's abundant nobody cares any more about opengl it's dead so uh one thing about the vigil is that the api design is does not really map very well to modern hardware it's not really when you learn bootcamp you realize what the hardware actually does and you understand that opengl doesn't really like i will give you a very small example since so many of you actually are interested in rendering you know in opengl you can like set the vertex buffer you can set uh the textures in use you can set uh a lot of uh rastering operations like the winding of the triangles or if you draw lines or if you write uh quads or quasi nodes anymore triangles lines points you can change a lot of things and then you call the draw function when did you know that when you do all these things changing the state opengl actually is patching the shader and actually it's modifying the code of the shader it has a shader in memory that you bind the shader you change all these things then it binds the shader and if you change like the shader it needs to re patch the shader with all the changes you have done so there's a lot of code invisible code inside of ngl that you don't know that is patching the shader and doing a lot of work every time you change those status the apis are like vulcan which are called uh it's not entirely stateless but it's mostly pipeline based it's called pipeline base you just create that one object with all the states uh and if you want to change the state you just create more of those objects you know if you want uh the pipeline has like the shader and all the states you set in opengl like the vertex buffer format and the the geometry and the analysing 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 this is really fast so vulcan forces you to be uh to just get your your your data together properly and when you set everything together it's just just much faster so these kind of things make it much more optimal to draw a large amount of actions when we started porting the engine to woolcon the first thing we noticed was a huge increment in performance even in the 2d engine because we just called gl draw arrays like every time we draw a primitive and just using wool gun even if you are doing the same amount like not the same but similar amount of cards the performance was like whoa what's impressive how much it it uh so when vulcan is more modern than benjiel it's smart up to more up to date for example if you want to use ray tracing extensions now uh there's going to be it's only nvidia but soon there's going to be like an official rtx implementation for glucan so this is not any longer in opengl because as i said eventually uh so the all the new extensions like hdr rendering a lot of these things are just coming out for vulcan opengl is just ignore nowadays uh it kind of this sounds a bit worse or weird but it really works as an entry barrier uh because we have the problem that for example all the rendering we we thought that we were going to making opengl 3.3 compatible which dates back to directx 10 like 2008 to 1079 i think i think around that so you can run all the hygiene goto 3 renderers and shaders in really old hardware and truth is that that doesn't work in that hardware because the hardware has too little video memory to delete limitations it's low so with vulcan we can just make sure that if you have all hardware you're not going to to ruin it because it's just designed for modern stuff and we don't have users complaining i go through this low because yes you run it in 10 years old hardware and you're pretty pretty effects on of course it's going to be slow so now it's a nice entry barrier which means that we can focus on like optimizations and new features and everything and people that uses bootcamp will be able to run it and if you have a computer that does not support vulcan you're going to be using the opengl renderer which is the compatibility render which which is the same 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 a lot is creating a new a new layer which is rendering device uh now this is very interesting uh the rendering aps actually even if bootcamp 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 uh the the frame buffers and even some apis like metal don't even have that uh you have the the shaders the pipelines and then the the render list and that's it there's not so much uh actually amazingly uh even if in some aspects vulcan is really complicated uh 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 d4 we're going to have the resource error which is the the main abstraction for rendering is it's the the entry barrier for anything that has to do with with rendering and we're going to have two rasterizers one is going to use fds rendering device and rendering devices what abstracts will come we can make it attract now metal or directx 12 or there's some people forcing it to playstation we can't do it because we're open source but they can use support it's much easier to port rendering device to bootcamp and then we have a raster user that is glds2 uh maybe we we will add some gles3 functionality uh and this just uses opengl es so we have a completely different i mean visual server abstracts 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 vulcan and everything just works whatever is done in opengl doesn't appear it's just hidden so so well the other thing that users requested a lot of things that you couldn't do before that you will be able to do english for is that you will be able to access from your scripting language or whatever you want like c plus plus two rendering device which is the the bull can abstract like the rendering abstraction so if you actually want to do like more advanced custom rendering on the engine now you 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 uh it was one of the most requested features uh and yeah it's eventually portable to more apis uh there's like 14 if you wanted to portal 3 to the playstation you have to write the entire raster resource which is really huge for gold four you just put like rendering device and that's it it's much much smaller so another thing we're going to have in gold four we we decided it was the best way to go is at first we tried to do our rendering uh woolkind rendering code that supports both mobile and desktop but as 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 algorithm is going to have a high and low end bootcamp renderers this is separate from the opengl legacy renderer so the high end will be just for for for desktop we are just going to use like for example let me give you a few examples like on desktop bootcamp has something called uh descriptor sets which is the amount of uh like you could call it uniforms and other things that you combine to shaders in groups uh like on desktop it's like i think the limit is 16 but the mobile is four so you you when you have more you can optimize more a lot of things uh so we were being restricted to fortress from a while then at some point it's no it's not worth it let's just make that hike and use this for example on desktop you can have something called uh indirect texturing indirect texture addressing 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 can't do it so and for example on mobile you still have really low texture limits like 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 some purchase textures that 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 really make sense to make something that works for both you know you're going to be crippling the desktop uh just to make mobile work so you're we're going to have high and low end runner i think for vulcan it makes the most sense also uh for mobile there's something you can do which call it's a bootcamp feature which is called sub passes have you heard of surpasses what's passive sir something you can use on mobile due to home mobile chipset works like mobile have a lot of uh when you have something rendered when you render on on desktop uh 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 that touch the cell when you render and then at the end it graspers 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 different because it only says the last pixel that was around after it's like a mini d version rendering a tile so because they work like that maybe you want to have many passes like for example you do a different renderer and then the first pass you want to render all the materials and the second pass you want to do the shading so if you have sub passes you're telling the mobile driver that after this pass i'm going to the shading so if a tile is done doing the the rendering of the triangles it can go to the next pass while the other ties didn't finish so it's so different mobile and desktop are really different so you should probably if you're going to use bootcamp we can give you such low level access to this kind of things that it's a ways to try to make something that works on both just make one that works for mobile just won't 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 renderers at any time um well as i was saying before vulcan is designed for uh i explained to you this is just design for low uh bottlenecks right low amount of volume just very low driver ahead you just can it's amazing you just do a lot of call draw calls you can have like i don't know 50 000 draw calls in vulcan and it uses so little cpu compared to open shield that it's it's it's amazing so the first thing as i was telling before that we saw uh when moving from opengl to vulcan was the a massive improvement of performance when just drawing a large amount of objects to the or it's just a massive improvement uh one thing that people may get confused is that yes vulcan is faster but calling the api is mostly faster like if you have a very simple scene like uh just one room with a few things that are furniture and really complex shaders it's going to run the same in opengl and in bulk and because the shader performance is the same in both it is that doesn't change but if you have a really huge like scenario like a city or i don't know uh unders underwater or something really big that you can see really far away yeah bulkan 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 uh yeah that's kind of the same for 2d it improved the performance improve hugely it's impressive how how fast it is like for 2d it's very difficult like when you work on 2d on opengl you usually want to implement like things like batching because there's a lot of just put everything in an array and then send it to render because uh the cost of the draw call itself is kind of slow in in mobile especially mobile but with vulcan is like since there's no validation between the drug rules or anything you you can't just throw the the comments and it doesn't seem to really have any uh performance impact that's really impressive how how well the drivers are optimized for a very high amount and if you want to even optimize it better what you can do is simply like run like the render list you can separate it uh you have the imaging you want to render 20 000 objects you can run threads that each like you want to run eight threads each 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 organizations are great so this is really important it it's a very big advantage of pulcan but uh it's very often overlooked uh 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 for came out i think i i remember reading that reading that amd decided to rewrite their opengl driver and 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 have to start adding patches to make it work better with different games by the time they 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 the the top company that make these kind of things so opengl is very complex it's very difficult to optimize because you need to like you need to optimize the way you think games are going to use it but then games may use it a different way uh it's typical software design problem uh if you try to make something super flexible uh you're going to end with something complicated and then it's not going to be useful because user users don't really want to use it that way they still want to use it to different so with glucan they were like we suck we can't make this kind of complex apis but just just let's make something really low level and let 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 backs because it's just much smaller if you look at the bulk and driver like the messer drivers it's just much smaller it just maps much more directly to the hardware uh this is very they're very interesting i think this was a really good decision at first when you started learning bulk and you're like what this is so complicated why they made it so complicated but in the end you realize that uh what you write is going to be a lot more effort that is going to work much better and it's going to be like less buggy when you run it on different hardware uh which isn't to say that uh you just if you have nvidia or amd uh for example you still need to try everywhere because there are things like barriers for example vulcan has something called barriers which you used to a synchronization points between different kinds of uh of tasks like for example compute you don't you do compute and then you want to use what you did for compute for rendering and using architecture you need a barrier both for for waiting until the compute is done and for converting the resulting image to something readable uh by what is rendering you need this kind of barriers uh which you need to put everywhere in in bulking and bulking bars are really complex they have a lot of options and not not all the hardware implements all the waters you know i think nvidia implements them like more coarse and amd is more fine grained so an intel intel just like doesn't care about anything i think it's like my experiment with intel is whatever you do even if you forget all the warriors still works so it's really weird so intel is just weird but uh but the thing is uh 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 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 it's it's raster pricing i don't think they even support warriors in intel but well that's what he was saying less complexity is uh less points of fine you still have to test in all the hardware but let's prontobacks one problem we have with opengl is that opengl doesn't have a standard way of uh 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 before it still has like uh it still has like a delay because the driver waits until everything is ready to to to render to just actually compile the shader so there with opengl we have a lot of styles all the time so users have to resort to doing half like making like a loading screen that be that actually is a plane that has all the objects that need to be rendered you know 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 uh with vulcan what they added was is something called spear v spear vis like a shader byte code you compile glsl you can actually compile hlsl which is very popular because it's the microsoft one uh people that do rendering prefer directx i don't but uh hlsl is very popular i i think i don't like it honestly i think this glsl is nicer but well anyway uh you can compare to spear v from either of the languages uh on on vulcan and the interesting thing is that spirit is not really a shader by code that x that gets executed by the by the gpu it's more like a middle you know if you have seen compiler theory it's like the it's like the ssa form of the of the shader it's kind of pre-optimized up to a point but it's still not a vital i mean it's not something you can put on a virtual machine and on a gp on rooney more like it so the interesting thing is that it is faster to go from spear v to the 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 glsr compilers you have for example the 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 power vr they make their own gpu so now we have the apple compiler for glsen so there's like 10 compilers for glsl uh and one of them is always going to break because parking text is is much more difficult than in theory it isn't but in practice it is parsing text is more prone than parsing just a bicode that has very specific instructions so spirovi 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 uh to actually the right code 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 speed with 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 got spur v spear v you combine uh with all the um rasterizer data like which kind of triangles which kind of frame buffer which will perform at everything all these you get the pipeline estate object the pipeline is platform dependent it's even driver dependent you can comp 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 you need to you can use to catch it locally the pipeline on your computer you have to catch it even saving the driver version there's a few articles about that there's pretty interesting because it's very easy to break something catching a pipeline state but the thing is that even that compiling spiritual pipeline is really fast compared to just all the whole thing uh in fact uh i don't want to go sidetrack too much but uh there's web gpu coming you've probably heard of web gpu there's a big discussion now you have we have apple on one side uh you have google microsoft and mozilla on the other side because apple wants to use something called wh lsl which is a text format and all the others want to use as pv for web gpu and it's been years and they haven't agreed apple really doesn't want to have anything to do with chronos they are even duplicated up in gl they are like say away chronos and all the other people are not experienced amazing why not use experience we have a lot of tooling for spirit which is amazing we can convert it within a lot of different languages so they are completely uh in in the completely i don't think they will ever agree so we probably see web gpu for with spear v for these browsers and with w hlsl for safari uh that's probably what's going to end up happening at this point because apple just doesn't want to concede anything so i actually went into arguments with people from apple because they really defend the stance on wh lsl uh and my experience just with godot on web gpu um but you're on webgl compiling a glsl shader it takes a long long time for what because it's so many validations for c security so just using bytecode it's probably still dangerous but it's faster so so that's the well another interesting thing about uh vulcan is threats uh when you hear about threads and bulkhead the only thing that probably comes to mind is what you heard about uh the the secondary command buffers uh you probably if you are going to read about bulk 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 is faster yeah it is faster but there's many things that are really cool that you can do with vulcan like the first is that since it takes pv and not glsl and even if it takes privy on whatever you want you can just compile shaders and threads and then you fit the spear v uh it's super super efficient uh 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 like shadow mapping uh i need to render like uh directional light shadow mapping you need like the four splits that are typical to this you can like just create one render list for each at the same time like as an example you can do a lot of really amazing uh optimizations in in in vulcan with that the other thing that is really amazing is all the all the cues with asynchronous texture and buffer transfers when you start learning bootcamp one of the first things you see the first is bulk and device and then you see the bulk and cues the bulk and qs are really interesting is 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 uh asynchronously what you do is you just use the transfer queue for that you just allocate the texture because texture location is completely independent of whatever 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 under thread so that's super super efficient and i really like that uh and you can do the same with buffers if you want to upload geometry textures everything you use the the the transfer cues for this or even if you want to do things on a thread for compute you can run compute at the same time as so all these kind 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 uh when you learn if you come from direct text 12 like uh or directors and you go to vulcan it it's going to appear really complicated because we can forces you a lot of things that are normally not necessary for desktop because these things are actually more optimal on mobile the secondary what i already told you talk to you about the the render passes you can just break the rendering rather passes so the tiles in the mobile gpu can do work in parallel even in separate presses otherwise it has to finish and then go to the next one this is more optimal the image barriers are interesting like for example uh you can use something as a 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 uh since you have to specify all the conversions between what you're using the image for you can actually take a lot of interesting optimizations uh so yeah it's interesting because it 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 uh there's a lot of uh how you call it like a lot of internal politics in rendering it's amazing uh so nvidia sabotage open cl so what they ended up doing it uh and yeah apple proposed it and then abandoned it it's it's so weird so the interesting thing about compute is in vulcan is that you just use it with glsl uh it may seem a bit weird because people use compute just c open cl or c uh cuda but gls is pretty nice for compute i mean you can still do things normally and and it's pretty like to the point you know uh and a lot of optimizations can be done like for example normally in opengl you 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 like the middle line which supposedly it's faster so well there's a lot of things but in compute you just don't you just run the compute directly you don't have to go through the through the drawing the geometry it just does compute so it's super interesting and we are actually exposing uh 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 you can like if you want to make a game that has like 10 000 enemies you can write totally destroy your cpu trying to do this or you just can use compute and compute works fantastic and the interesting thing is and in bulk and you can have more than one device bootcamp has the bk device you can have more than one dbk device so you can just have your device for rendering and you can have your device for uh doing game logic uh which is really interesting especially on desktop uh but you can do really complex in logic like internally it's going to still like send one thing at the 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 with compute now uh i think this is not something that is used much in game development but i've seen compute a huge opportunity to optimize lots of types of gameplay so and this is just a few goals related things because the talk is about one thing that we are doing in the new rendering a lot 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 it a in an effect you give you an option you want to look ugly or pretty like quality low and high and user will always put height because like 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 don't know is moving on everything related to uh the quality and performance with the general settings of the engine and we put it like this is low this is fast uh hoping that this will be uh a bit more um obvious for the user that you're like making these mistakes and also this is more like a way that god works 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 setting for mobile and having the quality settings on the on the project settings for example if you want this is the depth of field setting you know uh box is super fast but looks like a box is kind of a weird debug feel effect but it's super fast if you use it for something small it's okay uh and circle it's super slow but looks amazing it's only for like ultimate dedicated gpus so what you can do is you can put an override uh of deposit shape if you are targeting mobile you can override this and go from circle to box and you can have for example right for low and high end renderers and the high end can use circle the low one can use hexagon for example so this is pretty cool of the new things we are doing and lastly this is the last item um one thing that uh we went from opengl to bootcamp but we never had heretics rendering so we always kept all the like the interpolation the mid-maps and everything in the texture which is what happens in opengl in godot 3. but now textures and samplers are separate and it's really cool because if you separate them you have you can have as many textures as you want just reducing the numbers but now users will have to move the 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 in the material no longer in the texture that's the last change we have to do this again improves performance and make sure you have unlimited textures but the way you work on it is just a bit different but that's all so well this concludes the talk uh if you have any questions or want to know more sorry know more about the daughter of william or anything i'm here to answer questions uh you were first sorry yeah since you mentioned web gpu what are your plans here ah that's a good question uh it will be interesting to make a rendering device for web gpu because it's it's very interesting i don't think there is any bull can uh over web gpu uh could it could be easier to at least test it if we had a vulcan wrapper for web gpu uh but we're probably going to have to write the backend for it that would hopefully will be very interesting i don't see that it's going to be this dispute between apple and the rest of the world doesn't seem like it's going to get solved so uh i can imagine that the spear v2 guys are going to make something to convert spirit back to that exchanger so it runs an apple uh so yeah that's kind of what i think about it i guess it's uh it's going to work eventually it's going to be a bit messy on safari probably but yeah they just implement it eventually uh probably forgot 4.1 not 4.4 which more or less is stable now but yeah and you want to draw something is there any reason for apple to want their ws i have no clue oh 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 uh i think apple exited chronos at some point because apple was part of the volcano working group up to some point and then they exited cronus and they have nothing to do with chronos anymore uh maybe that has anything to eat but but what gpu is actually w3c it's not uh chronos but spirit is chronos so maybe because they don't want to have anything with chronos i really don't know it's just speculation i don't know what that's also um does ios support volcan if so it has a spare v support no ios and mac os don't super wukan they support metal the thing is that uh it's not really a secret if you dig into it but apple knows that nobody really cares about metal because the the the gamers don't really use mac so what they did recently is just add more features to metal so the molten bk which is the wrapper the brass bulkhead over metal just works better uh they secretly did it let's say uh apple is you know it's a very secrecy company you won't see them at any event they don't have the public engineers uh it's it's like so in the end it works really well we may eventually import uh rendering device to metal if we see that there is a benefit and an improvement in performance because why not otherwise but in the meantime right now it's working with multi mbk works really well i run it on macos and it just works so it's okay any other question oh well let's go right to left sorry you started okay um when you talked in the beginning not about running but about get off um you mentioned how the development is going and everything but how about users games using your engine how does the community look from this direction and also because like now we're talking about devices mac ios everything do you know where godot is used that's quite more well if it's the question is more about the community uh if i understand uh what they use it more and what they are expecting uh the biggest complaint the program is started as a 2d engine mostly it has 3d but almost nobody use it so nobody even bothers to use it on reportbacks 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 features and a lot of things so at the same time we realized we were going to continue working up in gl because it just didn't work in a lot of levels i'll say so we had to set the rendering stone for two years uh fix a lot of the bugs because 3.0 was a very big release and now we are porting everything to vulcan and trying to satisfy all the demands from users about like improved performance more features more modern features more portability working on the platforms so right now the direction is trying to cope with all the use of demand uh it's like the engine is slowly going from mostly to the engine to a 3d engine too but yeah it takes a while until everything i think the vulcan one is going to be really cool i mean it's going to be almost on the same level as using like the high and rendering unity or unreal so it's going to be more or less in that same level i hope uh or at least it will be close enough that everything else that is missing can be added without that much effort so yeah that's the situation uh wait we weren't we're going yeah yeah so um the vulcan branch is now merged into master does that mean that uh next week's probably or in the future probably yeah oh no no not close uh it's going to be broken for for a while in master i mean it's going to you shouldn't board your game to vulcan yet some people some really some people that love living on the edge are actually publishing their name on the woodcam branch but you should probably not do it probably by the middle of the year that will come branch will be complete uh like may june or july and then we will focus on stabilization so release will probably be the gold for second uh half of the year it will be very useful probably by the middle of the you already will be able to use it fine it's just going to have bugs uh just for developing it's okay for releasing maybe not so much and when we can actually release 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 yeah sorry is it going to be possible to put games from 3-2 to 4. uh yeah uh porting games from godot 3.2 to 4 should be much easier than it was going from two to three which completely broke a lot of things uh most of the most of the data is remains compatible you should be able to put your project maybe the scripts the 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 will be really good uh he's doing them not me uh and uh but it will be really really much much better uh we actually may make a screen uh we can just parse the old ones and compare to new ones probably so probably an export tool will will be needed but compared to the pain that she knows sporting your game from two to three this will be a lot less a lot less painful so yeah that's it we have time for more questions over here yeah okay so good for what is what is it gonna use on desktop windows platforms uh do the windows desktop platform exist on superbug oh you mean the older the older computers that have a gpu that don't run vulcan now that's going to keep using opengl the thing is that those are all and have i mean what limits you in those platforms is not so much uh the feature set but the resources and the performance like if you make a game uh with vulcan in mind you're thinking of the the gpus that have maybe four gigabytes of video memory uh are really fast uh the older devices that don't support bootcamp which is kind of like the directx 10 level devices uh they usually only have like 200 megabytes of video memory and they are usually like just lower uh they don't have usually as much for maybe a high gain one has a bit more but in average they are not like 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 and it's just going to work i mean it's not going to have a lot of difference but for 3d games if if you want to make something that uses all the highest and rendering features on 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 a box account 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 that's kind of the the goal so we have more time here any other question so yes about the rendering uh the render ring back ends um i don't know if godot has a pdr pipeline yeah it is pbr well uh if you wanna implement new rendering techniques you have to implement to implement it for each backend say for the low end renderer and the high end renderer for broken uh no that should be the same it should work so one thing we discussed a lot which may be interesting for you if you are into rendering is that god is mean to be an easy to use game engine so one thing we are not implementing as an example is temporal anti-aliasing because it means you need to let users that make shadows understand that they need to get a hold of motion vectors and it's super difficult i mean it's already difficult for really big games or that have a lot of budget so expecting our users to 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 a lot is going to use forward rendering with cluster lighting which is kind of uh trendy now it's 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 uh so maybe then you have the problem that some things have more aliasing that are not just the geometry uh so we are like using other techniques to like reduce that aliasing and still have very stable image as an example the lower end rendering may use a different technique maybe it's just forward single pass or soft or maybe on the older devices will be forward but multi multi-pass which is better for real stuff but the shader you write gives you like glsl to write your your code but it's not the glsl from opengl it's like a managed gsl that is very easy to use has all the complexion 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 and for the glowing and you don't have to do anything and if you want to implement like custom lighting you can like write like shaders and you have 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 you want to read something custom you do that and then that's going to be compiled as different the different rendering technique will still run your your shader in different ways and you just write it once and it works any more questions or are we okay are you running validation validation layers oh yes yes to the back it's always we always run bootcamp validation you see errors in your work of the port uh i think there's nothing now uh but uh who knows i mean i usually develop on nvidia and test an md and intel but right now it's not meant to be stable so there's probably some errors if you're running different uh when it's stable it's not going to have any errors of course but right now yeah it's it's typical to use something that works in one platform and then the other uses also nvidia has their own validation layers besides the lunar g so uh usually it throws different errors the nvidia ones are usually like i don't care about that so just turn them off uh 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 uh but yeah the idea is that you can anyway turn it on and run it and uh we we're going to have uh uh one of our contributors is setting up a farm that if you have like 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 rigorous and inequality if there are validation layer errors that appear so to avoid this kind of cases we are doing trying to use ci for this kind of things we actually got a really nice donation from amd to the gpus and cpus to make this this little farm so it's going to be pretty cool once it's working yes uh is there any key differences between what gpu and vulcan or is it like webgl web gpu is more like metal because apple proposed it so yeah it's it's so funny because sorry i don't i shouldn't say that but but they proposed web gpu with wh lsl and everybody was like well that's been good term with apple we could have done wolkan for the web but let's do web gpu you know because it's okay metal is easier to validate than vulcan uh and they went with apples and they told up yeah but we'd like to use spear v not really an apple was well let's discuss it like four years later i police that no way not touching spurvy so yeah that's what's happening sorry to interject if this is not correct um you're going to give more information really you're you're all witnesses to this don't forget okay so yeah uh i hope actually i hope this is solved at some point because it's really annoying to be an honest it's been webgl sucks pretty much uh it has too many problems it's okay for simple things but porting a game engine to webgl uh has too many shortcomings especially shader compilation is just a big big pain uh so i hope uh if if this situation is resolved at some point that would be fantastic i really hope uh this this gets solved so i will assist your presentation any more questions or are we okay okay thanks everybody you

Channel: FOSDEM

Views: 5,835

Keywords:

Id: -39yxfc9DEA

Length: 58min 54sec (3534 seconds)

Published: Thu Aug 20 2020