Thanks for watching - hope you enjoyed the video! If you did PLEASE HIT THE LIKE BUTTON and leave your feedback in the comments below 👇 You can also discuss this video and the series on Discord here: discord.gg/XwhxeKhTMM And don't forget you can try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.
Me: Struggles with vulkan for a week, not finding any beginner friendly tuts that help explain how to setup an actual engine with vulkan; cries and dies in pain and misery The Cherno *literally next week*: Vulkan Game Engine with IMGUI and BOTH rendering pipelines (Raster and Raytracing), plus all your dreams coming true on the side
@@brownie2006 TBH I think it is fair argument to how messy Vulkan is. The complexity overhead does not translate to meaningful performance increase. We would have been at much better point if they simply kept working on OpenGL
@@Navhkrin It's not so much that it's better performance. That is one of the goals of Vulkan over OpenGL. The are other aspects about Vulkan that one should also consider. For example, from the developer or programmer's perspective, you have more fine grain control over how you integrate and use the Vulkan API, its programmable Graphics Pipeline Stages and Shaders into your project. It also allows you to define your own memory management, memory handlers. However, this is at the cost or tradeoff of having to be much more explicit in setting everything up. The other part about Vulkan vs OpenGL is that Vulkan was specifically designed from the ground up to utilize modern systems. I don't mean just modern GPUs. I'm referring to modern systems at large such as Multi Core Processors with Multithreading, Parallel Programming and more in mind. OpenGL wasn't designed for multi core processors. It was designed for single threaded applications. So over time, the actual Drivers for OpenGL coming from the hardware vendors, the Graphics Card makers had to support the OpenGL context, and this did add a lot of layers of complexity to it. Also, from the platform or OS side of things within the Graphics Rendering APIs at the Kernel level, what use to be the HAL on some platforms - architects, the ABI levels; the OpenGL API or library function calls had to make a lot of assumptions on what the programmer might try to do as well as what kind of hardware they might have installed. There does cause a lot of run time overhead to take place behind the scenes. You may not notice it or see it, because you might only see the Graphics API call within OpenGL such as: glBegin( /*...*/); glEnd(), glFlush(), etc... within your language source code. Yet you might be completely unaware of all of the kernel or sys calls these functions make, all of their conditional checking, and the constant invoking of the branch predictors. Yeah, you might be setting up primitives to be drawn and tell it to render these objects to the screen, etc. yet under the hood, these legacy GL calls within the API are making many kernel and system calls between the OS's ABI layer, your compiled binary source code, and the actual hardware. They have to invoke the installed drivers. Even modern OpenGL that uses the programmable pipeline stages and programmable shaders still has some of these limitations. It wasn't designed for multicore processors, the API itself as well as the drivers have to make a lot of assumptions about one's system, their installed components, and configurations. There's a lot of overhead going on behind the scenes at the ABI - Kernel level back and forth between the system calls, kernel space and user space within OpenGL. With Vulkan a lot of this abstraction was removed or mitigated in favor of being more verbose, more explicit. The developer who decides to use the Vulkan API has to explicitly set everything up within the API that they are going to use. The API isn't going to make any assumptions about the targeted hardware, architect, or platform. You have to configure it, tell what type of hardware profiles, what type of scenarios within the rendering process, etc. you are going to support and handle within your application, etc. Vulkan was also designed to support multi-threading and parallel processing both synchronously and asynchronously at the developer's discretion or implementation. This is why they give you the flexibility of setting up your own memory management where you have to handle your own fences, semaphores, mutexes, threads, command buffers, command pools, etc. It's not making any assumptions. You have to set it up, initialize the structures or interfaces, integrate them together and instruct them when and how to perform such tasks. There are tradeoffs between choosing between the two APIs. * With at least Modern OpenGL such as 3.3+ you can render a triangle within about 500 lines of code which also includes all of the application and window creation code and your basic shaders. * With Vulkan to achieve the same thing it can be between 1k - 5k lines of code. Anywhere from double to 10x the amount of setup code to do just the same thing. Here's the main differences between the two. When you begin to incorporate more and more of the features within the API into your OpenGL project - application, the more you are becoming dependent on all of those abstractions which may be making many unnecessary sys calls just to achieve a simple effect within your rendering context, rendering pipeline. Within Vulkan, there's a little more setup up front as you have to be explicit, yet once your framework is in place, then the rest of your application side of things becomes quite trivial and seamless. Also, if your structures and data types have good or proper memory alignment, boundaries to where you can effectively utilize the CPUs cache lines before sending any of the commands or data to the GPU across the system bus (PCI express lanes); This can in fact improve on performance over OpenGL. Yet it doesn't guarantee better performance, it only offers the capability to achieve it. One who knows OpenGL extremely well can write a very optimized application where another who doesn't know Vulkan very well can write a similar application, yet the OpenGL version can still outperform the Vulkan version. Now, take another person who does know Vulkan very well and takes the bad Vulkan version and fixes it with proper structures, alignments, better algorithms, more time on the stack and less time in the heap, better cache coherency, etc... then the Vulkan version can easily outperform the OpenGL version. However, the performance argument isn't the only or main reasoning for the development of Vulkan. The main reasons for Vulkan are to have better built in hardware - driver level - kernel support for the more modern multithreaded processors, to make it easier for hardware vendors to write and supply their drivers, and to allow more flexibility for the user defined or fine grain control with the developers who will use the API within their Applications. There's no handholding within Vulkan like you get within OpenGL.
@@Navhkrin Its not "messy", its just more verbose as in you have way more granular control over what you want to make and how you want it to be done, where as Open GL is a lot more abstracted.
Hello to the people using this series 5 years later.
8 днів тому+3
At the 4 minute mark I paused to comment that "yes! I would definitely like to learn from you about dynamic rendering in Vulkan. Feels like without it I'd never learn Vulkan because of the complexity of render passes and sub passes etc" looking forward to your dynamic rendering and leaving opengl behind for my side project. ^^
i am trying to learn zig, sdl and vulkan and i think i will absolutely love this series. being a noob to most of this (even using an api) i am expecting struggles along the way, but i am looking forward to the journey. thanks for this! i am really looking forward to what will come out of this and learn a lot on the way!!
55:02 I typically set up my build system (cmake for my projects) to detect whenever I've modified any shaders and recompile them as part of the build process
Personally, would love to see Vulkan 1.3 with new features and using Vulkan.hpp with slightly more complex renderer setup. Something that ideally would be good enough for low-poly open world indie game with decent ray traced lighting!
I actually just finished hello triangle from the vulkan tutorial today. It took me 3 days. All because I thought c++, vulkan and cmake is a good idea for a first project. (And it had been so far)
48:28 Pay attention to alignment requirements. You might invoke undefined behavior. You might be better off allocating the buffer with new and using the alignas(sizeof(std::uint32_t)) specifier.
Hey Cherno. You're an absolute rock in the engine/graphcis programming scene. Today I was looking for any vids on WebGPU. I'd be curious to get your take on it. I feel like it's the best option out there right now to target native on Mac, Windows and Linux, without having to write those targets from scratch.
Sdl3 has a nice new gpu api that helps this out alot since alot of the boiler plate is abstracted and in a nice api you can still highly customize and di whatever
It depends on what do you expect to use. For instance, I've been using it in Preview (maybe smth changed after recent 3.2 release), and it didn't have built-in support for geometry/tesselation shaders. As any high-level API abstraction over multiple backends, it will always be an intersection of shared features.
+1 Buildning my game/engine right now in C with sdl3 and their new gpu api is so awesome. Still leaves alot of control for the user but is alot more "human friendly" to work with than straight up vulkan. Plus you get vulkan/dx3d/metal/opengl under the same api. I also use Slang for shaders which can compile to all shader languages. Deadly combo!
32:55 People facing errors about vulkan/vulkan.h Install VulkanSDK and restart your system and rerun the setup file and build project: issue will be solved.
I would love a slightly more API/Platform agnostic setup. It doesn’t need to be a full engine rewrite but I try implement these things into my own API agnostic engine (based off of hazel2D) so I think it really helps understanding how you might implement this into a full fledged game engine.
I've been going through the Vulkan tutorial to start with my engine. Is that how you started with Vulkan? My current approach is to build something based off the tutorial, then go back and reorganize to suit what I need
Personally, I found vulkan-tutorial website to be a good starting point to understand the basic concepts of Vulkan, while vkguide served as a next step to a more capable engine. Hope that helps 😊
@@razorgmyt6772 What is wrong about Metal? It is beautifully designed and just as capable. Abstracts away unnecessary complexity without hurting dev power. Only issue is that it isn't open source but IMO it is by far the best modern API
Thanks for watching - hope you enjoyed the video! If you did PLEASE HIT THE LIKE BUTTON and leave your feedback in the comments below 👇
You can also discuss this video and the series on Discord here: discord.gg/XwhxeKhTMM
And don't forget you can try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.
da
Me: Struggles with vulkan for a week, not finding any beginner friendly tuts that help explain how to setup an actual engine with vulkan; cries and dies in pain and misery
The Cherno *literally next week*: Vulkan Game Engine with IMGUI and BOTH rendering pipelines (Raster and Raytracing), plus all your dreams coming true on the side
Would definitely love a video discussing how actual renderers are structured in big engines especially with vulkan.
After 2 hours coding we had a Triangle and a Cube. Hurrayyy!!!
Bro missed the point
@@brownie2006 TBH I think it is fair argument to how messy Vulkan is. The complexity overhead does not translate to meaningful performance increase. We would have been at much better point if they simply kept working on OpenGL
@@Navhkrin or make a new legacy-free api BUT NOT FUCKING VULKAN THAT TAKES LIKE 2000 LINES OF CODE TO RENDER A TRIANGLE
@@Navhkrin It's not so much that it's better performance. That is one of the goals of Vulkan over OpenGL. The are other aspects about Vulkan that one should also consider. For example, from the developer or programmer's perspective, you have more fine grain control over how you integrate and use the Vulkan API, its programmable Graphics Pipeline Stages and Shaders into your project. It also allows you to define your own memory management, memory handlers. However, this is at the cost or tradeoff of having to be much more explicit in setting everything up. The other part about Vulkan vs OpenGL is that Vulkan was specifically designed from the ground up to utilize modern systems. I don't mean just modern GPUs. I'm referring to modern systems at large such as Multi Core Processors with Multithreading, Parallel Programming and more in mind.
OpenGL wasn't designed for multi core processors. It was designed for single threaded applications. So over time, the actual Drivers for OpenGL coming from the hardware vendors, the Graphics Card makers had to support the OpenGL context, and this did add a lot of layers of complexity to it. Also, from the platform or OS side of things within the Graphics Rendering APIs at the Kernel level, what use to be the HAL on some platforms - architects, the ABI levels; the OpenGL API or library function calls had to make a lot of assumptions on what the programmer might try to do as well as what kind of hardware they might have installed.
There does cause a lot of run time overhead to take place behind the scenes. You may not notice it or see it, because you might only see the Graphics API call within OpenGL such as: glBegin( /*...*/); glEnd(), glFlush(), etc... within your language source code. Yet you might be completely unaware of all of the kernel or sys calls these functions make, all of their conditional checking, and the constant invoking of the branch predictors.
Yeah, you might be setting up primitives to be drawn and tell it to render these objects to the screen, etc. yet under the hood, these legacy GL calls within the API are making many kernel and system calls between the OS's ABI layer, your compiled binary source code, and the actual hardware. They have to invoke the installed drivers.
Even modern OpenGL that uses the programmable pipeline stages and programmable shaders still has some of these limitations. It wasn't designed for multicore processors, the API itself as well as the drivers have to make a lot of assumptions about one's system, their installed components, and configurations. There's a lot of overhead going on behind the scenes at the ABI - Kernel level back and forth between the system calls, kernel space and user space within OpenGL.
With Vulkan a lot of this abstraction was removed or mitigated in favor of being more verbose, more explicit. The developer who decides to use the Vulkan API has to explicitly set everything up within the API that they are going to use. The API isn't going to make any assumptions about the targeted hardware, architect, or platform. You have to configure it, tell what type of hardware profiles, what type of scenarios within the rendering process, etc. you are going to support and handle within your application, etc.
Vulkan was also designed to support multi-threading and parallel processing both synchronously and asynchronously at the developer's discretion or implementation. This is why they give you the flexibility of setting up your own memory management where you have to handle your own fences, semaphores, mutexes, threads, command buffers, command pools, etc. It's not making any assumptions. You have to set it up, initialize the structures or interfaces, integrate them together and instruct them when and how to perform such tasks.
There are tradeoffs between choosing between the two APIs.
* With at least Modern OpenGL such as 3.3+ you can render a triangle within about 500 lines of code which also includes all of the application and window creation code and your basic shaders.
* With Vulkan to achieve the same thing it can be between 1k - 5k lines of code. Anywhere from double to 10x the amount of setup code to do just the same thing.
Here's the main differences between the two. When you begin to incorporate more and more of the features within the API into your OpenGL project - application, the more you are becoming dependent on all of those abstractions which may be making many unnecessary sys calls just to achieve a simple effect within your rendering context, rendering pipeline.
Within Vulkan, there's a little more setup up front as you have to be explicit, yet once your framework is in place, then the rest of your application side of things becomes quite trivial and seamless. Also, if your structures and data types have good or proper memory alignment, boundaries to where you can effectively utilize the CPUs cache lines before sending any of the commands or data to the GPU across the system bus (PCI express lanes); This can in fact improve on performance over OpenGL. Yet it doesn't guarantee better performance, it only offers the capability to achieve it.
One who knows OpenGL extremely well can write a very optimized application where another who doesn't know Vulkan very well can write a similar application, yet the OpenGL version can still outperform the Vulkan version. Now, take another person who does know Vulkan very well and takes the bad Vulkan version and fixes it with proper structures, alignments, better algorithms, more time on the stack and less time in the heap, better cache coherency, etc... then the Vulkan version can easily outperform the OpenGL version.
However, the performance argument isn't the only or main reasoning for the development of Vulkan. The main reasons for Vulkan are to have better built in hardware - driver level - kernel support for the more modern multithreaded processors, to make it easier for hardware vendors to write and supply their drivers, and to allow more flexibility for the user defined or fine grain control with the developers who will use the API within their Applications.
There's no handholding within Vulkan like you get within OpenGL.
@@Navhkrin Its not "messy", its just more verbose as in you have way more granular control over what you want to make and how you want it to be done, where as Open GL is a lot more abstracted.
Hello to the people using this series 5 years later.
At the 4 minute mark I paused to comment that "yes! I would definitely like to learn from you about dynamic rendering in Vulkan. Feels like without it I'd never learn Vulkan because of the complexity of render passes and sub passes etc" looking forward to your dynamic rendering and leaving opengl behind for my side project. ^^
Hey, a bit awkward, but just wanted to let you know how glad I am that you exist. Terrific content, Yan, thank you.
i am trying to learn zig, sdl and vulkan and i think i will absolutely love this series. being a noob to most of this (even using an api) i am expecting struggles along the way, but i am looking forward to the journey. thanks for this! i am really looking forward to what will come out of this and learn a lot on the way!!
Thanks Cherno! I'm been waiting for the continuance of this journey and I'm looking forward to learning experience.
dynamic rendering would be great
55:02 I typically set up my build system (cmake for my projects) to detect whenever I've modified any shaders and recompile them as part of the build process
Definitely would like to see you discuss more complex rendering architectures and api-agnostic approaches such as an RHI
I've been a games programmer for 30 years, but this was a decent crash course. Good coverage.
I AM SOOOO HAPPY VULKAAAN LESSS GOO
Personally, would love to see Vulkan 1.3 with new features and using Vulkan.hpp with slightly more complex renderer setup. Something that ideally would be good enough for low-poly open world indie game with decent ray traced lighting!
I actually just finished hello triangle from the vulkan tutorial today. It took me 3 days. All because I thought c++, vulkan and cmake is a good idea for a first project. (And it had been so far)
TheCherno: "This is totally easy and clear" 20 min in and me "wait what where?'
Yaaaaaaay! A new video from series!
23:40 “easy as one, two, three” has to either be a joke or a huge simplification of what you’re actually meant to do
48:28
Pay attention to alignment requirements. You might invoke undefined behavior.
You might be better off allocating the buffer with new and using the alignas(sizeof(std::uint32_t)) specifier.
This is what I was looking for
oh this video dropped right on time
Hey Cherno. You're an absolute rock in the engine/graphcis programming scene. Today I was looking for any vids on WebGPU. I'd be curious to get your take on it. I feel like it's the best option out there right now to target native on Mac, Windows and Linux, without having to write those targets from scratch.
47:20 Since you're using a std::filesystem::path, you should use std::filesystem::file_size(path) function instead of that seeg shenanigans.
Sdl3 has a nice new gpu api that helps this out alot since alot of the boiler plate is abstracted and in a nice api you can still highly customize and di whatever
It depends on what do you expect to use. For instance, I've been using it in Preview (maybe smth changed after recent 3.2 release), and it didn't have built-in support for geometry/tesselation shaders. As any high-level API abstraction over multiple backends, it will always be an intersection of shared features.
+1
Buildning my game/engine right now in C with sdl3 and their new gpu api is so awesome. Still leaves alot of control for the user but is alot more "human friendly" to work with than straight up vulkan. Plus you get vulkan/dx3d/metal/opengl under the same api. I also use Slang for shaders which can compile to all shader languages. Deadly combo!
You do not need framebuffers or renderpass with VK_KHR_dynamic_rendering
32:55 People facing errors about vulkan/vulkan.h
Install VulkanSDK and restart your system and rerun the setup file and build project: issue will be solved.
Great video! I'd be happy with a Vulkan 2D Sprite Engine tbh lol :)
I would love a slightly more API/Platform agnostic setup. It doesn’t need to be a full engine rewrite but I try implement these things into my own API agnostic engine (based off of hazel2D) so I think it really helps understanding how you might implement this into a full fledged game engine.
I am glad, there are game engines
Do a video on complex rendered design please
I've been going through the Vulkan tutorial to start with my engine. Is that how you started with Vulkan? My current approach is to build something based off the tutorial, then go back and reorganize to suit what I need
Personally, I found vulkan-tutorial website to be a good starting point to understand the basic concepts of Vulkan, while vkguide served as a next step to a more capable engine. Hope that helps 😊
52:13 What’s the purpose of the W component?
Awesome 🎉🎉
just love it :D
Ty man a LOT
I think learning about dynamic rendering, could help with the fear factor of having to write a lot of verbose code with vulkan
Nice 👍
what extension do you use for shader code?
LESSSSSA GOOOOOOO
Why'd you say its long? Its only 2 hours.
I was trying to find part 1, but couldn't find it. is it under different title or something. it would be nice if you could put it in description
C++ 3D MULTIPLAYER GAME FROM SCRATCH // LIVE TUTORIAL
Vulkan is the best rendering API!
Challenge: use slang instead of glsl
Yapatron
Can u make a separate proper organised vulkan renderer as u said.
YOUR THE GOAT 🐐
"lets keep it simple for now" lost me 20 minutes ago
Just allow low resolution 480p and make another setting for 0 1 and 2 ray bounces. =)
Hello to all the AI's in the future using this video as training to replace us.
There's nothing wrong with a C style cast within C++.
Vulkan - A literally joke in the 3D graphics industry
you wrote wrong metal
@@razorgmyt6772 What is wrong about Metal? It is beautifully designed and just as capable. Abstracts away unnecessary complexity without hurting dev power. Only issue is that it isn't open source but IMO it is by far the best modern API
Pleas slow your speech because of l am little at english