Vulkan is much more efficient than OpenGL. OpenGL also has a lot of nvidia driver issues so i moved on. This project is written in C. Base code from: vulkan-tutoria...
Huh? It's Not a Driver lmao. It's an application programming Interface. It isn't only to send commands to your GPU, that's the drivers Job. It Had many many built libraries to make programming easier.
@@MrSofazocker at the end of the day, these libraries and your code will work with driver and without it your GPU will not do anything So basically the dude above is right
But there are many ways for developers to interface with the GPU and every API has to choose one particular way. Some are harder to code but faster, like Vulkan, and vice versa like OpenGL. Like how some programming languages allow you to have greater control over memory allocation, which is really important for performance, but at the cost of developer experience. Its all a compromise. Making something thats perfect at both is a thing to aim for, but practically impossible.
@@askeladden450 @darellldark @MrSofazocker The issue you guys, is that the video shows a static helmet rendering. That isn't going to make any difference whether you do it on OpenGL, or Vulkan how many FPS you get (like the video is showing) by the time you have passed the buffers and are just rendering it each frame it makes no difference. So that is why this video isn't a great demonstration of Vulkan's speed. The GPU already has all of the data, it's just rendering it each frame from different angle which is hardly any code in the render loop.
@@Thegamecheats yeah, you're correct I was just adressing @MrSofazocker phrase "It's not driver". It's actually a driver's work to do things you've told by API calls About perfomance: the good measurement might be a dynamic lighting, I believe, with moving object around the scene? Is there better example to check perfomance difference between OpenGL and Vulkan?
Ok but I need another layer of abstraction to simplify and complicate things at the same time. It also needs a cringe name and convoluted licensing. This is actually pretty sweet I just couldn’t think of anything entertaining to write. 😅
The issue here is related to the visibility of Vulkan shaders; once they are rendered, they are fetched from the buffer. Since the buffer remains unchanged from the beginning of the program, it appears static. There is no shader actively running in real-time; it only works once.
Yeah both are made by khronos group. But Vulkan is not meant to replace opengl, but enable deeper control of the gpu. It is designed to reduce driver overhead and make your gpu go brrrrrrrr
@@forceofphoenixWith the Zink Vulkan userspace implementation of OpenGL now matching or exceeding the performance of native implementations, the intention of GPU vendors is to eventually replace OpenGL with Vulkan at the driver level. This is especially true with AMD's and Intel's native Windows OpenGL implementations not being the best. But this intention is also true for Linux. We've actually already seen something similar to this happening with Intel Arc, where they use DXVK in the driver to translate DX11 and older calls to Vulkan.
I also wanted to learn Vulkan in C, but found out that almost all resources and tutorials use C++. I haven't tried any graphics API before, and also haven't written any game engine, but after a bit of research I got really interested in trying Vulkan. I know that it is not beginner friendly, but I really wanted to use it. So, there was only one tutorial that covers a lot of stuff in C, called Kohi Engine series. I have tried a couple of episodes and now doubt about continuing, because I don't really want to build a whole application with editor, and etc. So, from your experience, is it difficult to follow official Vulkan tutorial and adapt C++ code to C? Because of the classes and libraries that isn't in C, I wasn't sure about this route, but I really want to hear your opinion. Maybe I should try it, after all.
Hi, think its not that hard to follow the vk-tutorial while rewriting the code in C (i have around 9 month of c experience). The most challenging thing is their use of vectors, so you have to work with dynamic arrays instead and have to do memory managment. Also they are using some c++ helper functions that you have to implement yourself (like "set"). But I recommend doing that because when you rewrite the code you are understanding it much more than following any tutorial from yt (even though I still not understand the overall structure in the program, so that is a hole other level). Libs like glm, fastobjloader can be replaced with c libs (cglm, fastobj (github: thisistherk/fast_obj)). And another reason is that C is simply the cleanest, fastest programming language after all (in my opinion)
@@forceofphoenix yeah, I have the similar opinion. Writing in C is just more comfortable for me. There is no much hidden from you, and you understand it better, so it can lead for better optimization. Because of that I wanted to learn Vulkan exactly in C. So, I think you are right about just trying it by yourself, so through the mistakes you can build better understanding of how things work. Thank you for your reply. It gave me much confidence. I will definitely try learning this way.
@@forceofphoenix My patience is what deters me from using Vulkan. It took me months to will myself past the first chapter and I haven't touched it in a while. It's just so .. boring. Too much busy work.
@@d1metron702 C is convenient for a standard like Vulkan because the headers are lightweight and there is no bloat to the interface. But I absolutely would not recommend writing any renderer or game engine in C. You are doing a disservice to yourself by going this route. C++ has been the industry standard for more than 20 years. C is great for embedded systems where you need absolute control over the memory footprint, an area where most C++ code out there would be useless. On this kind of real-time and high performance application though, you want these operators for linear algebra, you want to control the lifetime of your objects using destructors and move semantics. Depending on your approach to the engine you may want to have OOP. Templates are super powerful to get a lot of things done too, and the STL provides a bunch of containers that are generally safer than your own you'd allocate in C. I would recommend to reconsider. Rust would be fine too.
Is this PBR or the lighting is baked? If this is baked, i can't see why opengl would bottleneck on this, vulkan has a better control over the command queue and this enables you to make multiple command buffers to work in multiple cores but that's it, if you are just sending draw calls there's no need for these multiple command queues and the performance would be irrelevant.
if you have many draw calls the multithreaded nature can overcome the cpu bottelneck (as i understand it, concepts like frames in flight, etc). You are right that this scene is not representative of vulkans capabilities over other apis
one question how long are you learning C language now i learn c++ and want to do the same what you are doing in videos my english is bad i hope you understand me
since one year im coding in it. I think c is a simple but powerful language that is not bloated like c++. When you understand pointers you are good to go
I totally agree, but i had some issues with opengl in the past. e.g. the nvidia driver stores a copy of vram in system ram, vsync is stuttering like hell and so on
@@distant6606 It's not a mess that's how the lower-level GPU drivers work under the higher-level layers. The Vulkan way is to keep the low-level driver as simple as possible and let the application programmer screw it up instead. D3D and GL had a bit different strategy how they are layered: the D3D way is that Microsoft provides the user-facing API and high-level driver, the IHV writes the low-level services for the mid-level Microsoft driver. OpenGL provides only specification, the IHV writes the whole driver stack. AMD for example used shared low-level driver that was under both GL and D3D. One year AMD made more general abstraction of this called "Mantle" and it was AMD vendor specific API, but Khronos Group wrote specification called Vulkan which was heavily influenced/inspired by Mantle and made it fully Open standard and now a lot of IHVs have implementations on various OS and ecosystems. OpenGL driver can be written on top of Vulkan just fine to keep application developers life easier. This is kind of cool since, consider if the high-level API is universal and same for everyone there are less vendor specific bugs and issues since the low level VK driver is "simpler" to implement = less bugs, in theory anyway. Middleware support is the key idea here you use Unity, Unreal or something like that you can focus in making assets and game instead of rendering engine. Simple low level universal driver is a good idea. How Vulkan improves things from application developers side is that the "work" generated is just binary data that the VK can execute, your application programmer can generate the work to execute anywhere, in any thread but has to deal with synchronization as well. With OpenGL everything was (in practice) shoehorned through one "context" which was only allowed to be accessed from a single thread. There is a concept of shared context but it doesn't work all that great, should be forgotten and never mentioned again. Also, once some binary buffer is done it can be executed as many times as needed without touching the memory. Inputs can be blocks of memory like textures and uniforms, just raw bytes in memory. GL has some awesome stuff like uniform buffers and so on and on that allow similar optimizations, AZDO programming techniques and so forth, but the VK way is that it's just raw bytes and you then use them to build your own things more freely; it's just memory how you use it is where the magic is. D3D has this great idea back in D3D days, it was called "execute buffers" but developers hated it they said it was "too complicated" but it was pretty much the right way to go about these things it just took 20 more years for the industry as a whole to catch up. In OpenGL side something along the same lines was called "Display Lists", which captured all API calls into a buffer, which could then be "played back" which meant the GPU driver could keep copy in it's local memory and just get command in the command stream that execute this D-LIST, please. Very light-weight and "kind of cool" but it's deprecated these days, the NV driver still carries support for it though. GPU coding was just becoming simpler and unified but then Apple dropped the bomb: GL - deprecated, we doing our own thing (METAL). Well, FUUUUUUU... this was of course some years ago already but so far graphics / GPU coders have just been shafted in the 455. Yeah. That's what it is man, VK being a bit verbose isn't a big deal. Yeah.
vulkan is an API. ideally it should be invisible and all the performance would depend on your GPU
Huh?
It's Not a Driver lmao.
It's an application programming Interface.
It isn't only to send commands to your GPU, that's the drivers Job.
It Had many many built libraries to make programming easier.
@@MrSofazocker at the end of the day, these libraries and your code will work with driver and without it your GPU will not do anything
So basically the dude above is right
But there are many ways for developers to interface with the GPU and every API has to choose one particular way. Some are harder to code but faster, like Vulkan, and vice versa like OpenGL. Like how some programming languages allow you to have greater control over memory allocation, which is really important for performance, but at the cost of developer experience. Its all a compromise. Making something thats perfect at both is a thing to aim for, but practically impossible.
@@askeladden450 @darellldark @MrSofazocker
The issue you guys, is that the video shows a static helmet rendering. That isn't going to make any difference whether you do it on OpenGL, or Vulkan how many FPS you get (like the video is showing) by the time you have passed the buffers and are just rendering it each frame it makes no difference. So that is why this video isn't a great demonstration of Vulkan's speed. The GPU already has all of the data, it's just rendering it each frame from different angle which is hardly any code in the render loop.
@@Thegamecheats yeah, you're correct
I was just adressing
@MrSofazocker phrase "It's not driver". It's actually a driver's work to do things you've told by API calls
About perfomance: the good measurement might be a dynamic lighting, I believe, with moving object around the scene? Is there better example to check perfomance difference between OpenGL and Vulkan?
0:45 Ah yes that one random printf we always need to add just to make sure that the event isn't somehow getting forgotten.
Printing to console will forever be the best way to debug anything
@sel I usually use gdb, but yea, printing helps a lot.
fps of same render on opengl?
My CPU is bottelnecking opengl so hard, that my gpu is never at 100%
@@forceofphoenixand the result is..? :)
@@forceofphoenix I doubt the issue is with OpenGl...
But opengl can make it harder to write efficient programs @@desoroxxx
@@forceofphoenix No, it's as hard/easy as Vulkan you just need to learn
Ok but I need another layer of abstraction to simplify and complicate things at the same time. It also needs a cringe name and convoluted licensing.
This is actually pretty sweet I just couldn’t think of anything entertaining to write. 😅
I think you're looking for WebGPU 😅Not so sure about convoluted licensing but the name sure is misleading 👍
Yeah that's totally fair, but the good thing about that is that you have more control over the GPU than others APIs
Shading being calculated? Looks like the reflections are baked as they are rotating with the object
The issue here is related to the visibility of Vulkan shaders; once they are rendered, they are fetched from the buffer. Since the buffer remains unchanged from the beginning of the program, it appears static. There is no shader actively running in real-time; it only works once.
The reflections are part of the texture :-P
@@forceofphoenix So then you aren't demonstrating the speed of Vulkan its the speed of your GPU.
If I'm not mistaken, Vulkan is the candidate to replace OpenGL or is considered the successor.
Yeah both are made by khronos group. But Vulkan is not meant to replace opengl, but enable deeper control of the gpu. It is designed to reduce driver overhead and make your gpu go brrrrrrrr
@@forceofphoenixWith the Zink Vulkan userspace implementation of OpenGL now matching or exceeding the performance of native implementations, the intention of GPU vendors is to eventually replace OpenGL with Vulkan at the driver level. This is especially true with AMD's and Intel's native Windows OpenGL implementations not being the best. But this intention is also true for Linux. We've actually already seen something similar to this happening with Intel Arc, where they use DXVK in the driver to translate DX11 and older calls to Vulkan.
shout out to cglm the gigachad C graphics-oriented maths library. obviously based on GLM for C++ but still, saved my ass. i love it.
I also wanted to learn Vulkan in C, but found out that almost all resources and tutorials use C++. I haven't tried any graphics API before, and also haven't written any game engine, but after a bit of research I got really interested in trying Vulkan. I know that it is not beginner friendly, but I really wanted to use it.
So, there was only one tutorial that covers a lot of stuff in C, called Kohi Engine series. I have tried a couple of episodes and now doubt about continuing, because I don't really want to build a whole application with editor, and etc.
So, from your experience, is it difficult to follow official Vulkan tutorial and adapt C++ code to C? Because of the classes and libraries that isn't in C, I wasn't sure about this route, but I really want to hear your opinion. Maybe I should try it, after all.
Hi, think its not that hard to follow the vk-tutorial while rewriting the code in C (i have around 9 month of c experience). The most challenging thing is their use of vectors, so you have to work with dynamic arrays instead and have to do memory managment. Also they are using some c++ helper functions that you have to implement yourself (like "set"). But I recommend doing that because when you rewrite the code you are understanding it much more than following any tutorial from yt (even though I still not understand the overall structure in the program, so that is a hole other level). Libs like glm, fastobjloader can be replaced with c libs (cglm, fastobj (github: thisistherk/fast_obj)). And another reason is that C is simply the cleanest, fastest programming language after all (in my opinion)
@@forceofphoenix yeah, I have the similar opinion. Writing in C is just more comfortable for me. There is no much hidden from you, and you understand it better, so it can lead for better optimization. Because of that I wanted to learn Vulkan exactly in C.
So, I think you are right about just trying it by yourself, so through the mistakes you can build better understanding of how things work.
Thank you for your reply. It gave me much confidence. I will definitely try learning this way.
Ngl going through same thing rn. I have no clue on GUI stuff but recrntly found about GTK and might look into these stuff mentioned here too
@@forceofphoenix My patience is what deters me from using Vulkan. It took me months to will myself past the first chapter and I haven't touched it in a while. It's just so .. boring. Too much busy work.
@@d1metron702 C is convenient for a standard like Vulkan because the headers are lightweight and there is no bloat to the interface. But I absolutely would not recommend writing any renderer or game engine in C. You are doing a disservice to yourself by going this route. C++ has been the industry standard for more than 20 years. C is great for embedded systems where you need absolute control over the memory footprint, an area where most C++ code out there would be useless. On this kind of real-time and high performance application though, you want these operators for linear algebra, you want to control the lifetime of your objects using destructors and move semantics. Depending on your approach to the engine you may want to have OOP. Templates are super powerful to get a lot of things done too, and the STL provides a bunch of containers that are generally safer than your own you'd allocate in C. I would recommend to reconsider. Rust would be fine too.
Thx for 10k views and 270 likes!
All I see is you're transforming some points on a screen probably through the GPU entirely.
well that's what gpus are insanely good at
no shit sherlock
Would you be able to test this with a complex scene filled with many 3D objects, like something you might see in a modern game?
im currently recreating the minecraft clone from my past videos with vulkan
Nice! Can't wait to see it! :)@@forceofphoenix
Ok but thats a flat shader the reflections are baked into the texture lol
Is this PBR or the lighting is baked? If this is baked, i can't see why opengl would bottleneck on this, vulkan has a better control over the command queue and this enables you to make multiple command buffers to work in multiple cores but that's it, if you are just sending draw calls there's no need for these multiple command queues and the performance would be irrelevant.
if you have many draw calls the multithreaded nature can overcome the cpu bottelneck (as i understand it, concepts like frames in flight, etc). You are right that this scene is not representative of vulkans capabilities over other apis
@@forceofphoenix oh, right, maybe you can queue multiple draws that makes sense
it's just displaying a 3d mesh with an albedo, no?
true
what is the color theme you are using?
only one processes in windows ???
vscode theme?
Just search for "red" on extension themes
looks like dark red theme by rogeraabbccdd
You aren't even computing anything, the 3d model you have has baked reflections, shadows, and everything. Vulkan is fast but no where near THAT fast..
Too bad it still doesn't hit the sweet spot at 20Khz.
maybe with an i9 14900ks
@@forceofphoenix then we'll get retina motion.
one question how long are you learning C language now i learn c++ and want to do the same what you are doing in videos my english is bad i hope you understand me
since one year im coding in it. I think c is a simple but powerful language that is not bloated like c++. When you understand pointers you are good to go
damn that's a whole lotta lines 💀
1500 lines and counting
Eso es god eso es a lo que quiero llegar
what is vulkan?
A state of the art (Graphics) / GPU API like opengl to render stuff including raytracing, etc
Can you please make a Vulkan development introduction? It's so hard to me to find good tutorial materials for noobs...
vulkan-tutorial.com/ its the best source i could find. just follow it and most importantly understand every step
computers are also freakingly fast
Yeah but OpenGL much easier than Vulkan, and useful for simple (2D or simple 3D) games
I totally agree, but i had some issues with opengl in the past. e.g. the nvidia driver stores a copy of vram in system ram, vsync is stuttering like hell and so on
sounds like a skill issue
@@arson5304 sounds like opengl is just a easy way to learn 2D/3D graphic programming, not a advanced one tho
why did it randomly just say hello!? 😭😭
i guess it's a response to the window resize event! Or the program simply wanted to say hello to youtube, who knows🤷♂
Defintely the second option. The Program has a ki executed on vk compute shader that developed contiousness and wanted to say hello. @@binaryecho_
now draw a triangle in less than 1000 lines of code
whats the song name? or if u got a playlist with such songs
its literally in the description. Its a random song from youtubes audio library. Just go to yt studio
i can see the lighting is baked though
the lighting is just in the texture, so no lighting is calculated
@@forceofphoenix yea, that model is very well designed though, from my perspective it looks like just a texture and a mesh, great work.
what your GPU?
is it calculating lighting, too?
and how did they get the window to render?
I wonder how much fps he would get if he was rendering a single polygon
around 7400 with amd 5800X
Do you have the source code?
@@mertcanzafer9901 go to vktutorial and go through the tutorial
damn
You stole this code from my great grandma...
1.6k loc?
you will achieve better results with OpenGL, bgfx, WebGPU if you are just a hobbyist. same with C++ vs C. unless you need >3000 fps :)
i call this a skill issue :P
wtf
I'm 99% sure that your FPS measurement is not measuring actual FPS. Just a BS output in Console which has nothing to do with actual frames.
3700 FPS is 270 microseconds per frame. Seems plausible for a program rasterizing a single mesh directly into the backbuffer.
On 4090
@@forceofphoenixop is just chilling with his potato 😂
@@minitbnn forsenE I C BAJS
you're too used to modern, bloated, unoptimised software
Ln 1699, Col 24🥲
The whole program is 1850 lines, but loading and rendering the object is only 200 lines
only xD, vulkan is a mess. i still remember that hello triangle chaos.@@forceofphoenix
@@distant6606only for initial setup. it will start to eventually make sense and be nice to work with
@@distant6606 It's not a mess that's how the lower-level GPU drivers work under the higher-level layers. The Vulkan way is to keep the low-level driver as simple as possible and let the application programmer screw it up instead. D3D and GL had a bit different strategy how they are layered: the D3D way is that Microsoft provides the user-facing API and high-level driver, the IHV writes the low-level services for the mid-level Microsoft driver. OpenGL provides only specification, the IHV writes the whole driver stack. AMD for example used shared low-level driver that was under both GL and D3D. One year AMD made more general abstraction of this called "Mantle" and it was AMD vendor specific API, but Khronos Group wrote specification called Vulkan which was heavily influenced/inspired by Mantle and made it fully Open standard and now a lot of IHVs have implementations on various OS and ecosystems.
OpenGL driver can be written on top of Vulkan just fine to keep application developers life easier. This is kind of cool since, consider if the high-level API is universal and same for everyone there are less vendor specific bugs and issues since the low level VK driver is "simpler" to implement = less bugs, in theory anyway. Middleware support is the key idea here you use Unity, Unreal or something like that you can focus in making assets and game instead of rendering engine.
Simple low level universal driver is a good idea.
How Vulkan improves things from application developers side is that the "work" generated is just binary data that the VK can execute, your application programmer can generate the work to execute anywhere, in any thread but has to deal with synchronization as well. With OpenGL everything was (in practice) shoehorned through one "context" which was only allowed to be accessed from a single thread. There is a concept of shared context but it doesn't work all that great, should be forgotten and never mentioned again.
Also, once some binary buffer is done it can be executed as many times as needed without touching the memory. Inputs can be blocks of memory like textures and uniforms, just raw bytes in memory. GL has some awesome stuff like uniform buffers and so on and on that allow similar optimizations, AZDO programming techniques and so forth, but the VK way is that it's just raw bytes and you then use them to build your own things more freely; it's just memory how you use it is where the magic is.
D3D has this great idea back in D3D days, it was called "execute buffers" but developers hated it they said it was "too complicated" but it was pretty much the right way to go about these things it just took 20 more years for the industry as a whole to catch up. In OpenGL side something along the same lines was called "Display Lists", which captured all API calls into a buffer, which could then be "played back" which meant the GPU driver could keep copy in it's local memory and just get command in the command stream that execute this D-LIST, please. Very light-weight and "kind of cool" but it's deprecated these days, the NV driver still carries support for it though.
GPU coding was just becoming simpler and unified but then Apple dropped the bomb: GL - deprecated, we doing our own thing (METAL). Well, FUUUUUUU... this was of course some years ago already but so far graphics / GPU coders have just been shafted in the 455. Yeah. That's what it is man, VK being a bit verbose isn't a big deal. Yeah.