Hi,
With all the buzz about the latest Graphics API Vulkan, I thought I'd create a series of tutorials and sample code. One of the things that was good about OpenGL was the vast knowledge base that was easily available online. This would be essential for any new technology/idea.
As you may already know, Vulkan is the latest Graphics API released by Khronos and most IHVs have already shipped the initial Vulkan implementations. There's already quite a bit of information available as to how you can setup and start using Vulkan, so I will skip that part.
There are however some ideas/concepts I would like to make it clear that I didn't see available from other sources.
In the introduction, I will have more of an FAQ based Q and A section to introduce Vulkan.
1. So, Vulkan is the next OpenGL right?
Vulkan is NOT replacing OpenGL. I repeat, Vulkan is not a replacement for OpenGL. Vulkan is a low level, explicit API that is designed to solve a specific set of problem(s). If, as an application developer, you're not facing those issues, then -- NO, you probably don't need Vulkan.
2. So, what is Vulkan good for?
Good question. Some of the main problems that Vulkan is trying to solve are-
- Having low CPU driver overhead.
- Be more explicit and give better access to hardware.
- Be multithreaded friendly.
- Be truly cross-platform.
- And a few more. The above are the most important ones.
As you may know, OpenGL has been around for quite a while (~24 years as of this writing). It has undergone significant changes, but fundamentally, OpenGL was not designed to solve the above mentioned three problems. GPU and CPU hardware has changed immensely since the first version of OpenGL.
3. What do you mean by 'CPU driver overhead'
The main job of the OpenGL(or any GPU driver software) is to submit commands to the GPU. The GPU is supposed to run parallel to the CPU and the main goal of the driver software is to pick up commands from the application and submit them to the GPU.
4. What is the overhead involved? (3) seems quite simple. Why is it so CPU intensive?
Conceptually, the idea looks simple. However, the driver has to do a LOT of operations in the back. By design, OpenGL was meant as an "easy" API. By "easy", I mean that the application developer need not have to worry a lot. He/She can just call the simple APIs and the driver makes sure things work. Now, with a simple API, the driver has to do a lot of things, namely maintaining certain heuristics about how the application is using resources, making intelligent guesses to provide optimizations, guessing how the buffers would be used by application, doing state validations, allocating and cleaning up of memory and tonnes of other things. All this work tends to create huge bottlenecks on the CPU. So, there could be applications that are bound on the CPU.
5. Ok, I understand that the driver has a lot of work, but what is this "bound by the CPU"?
An application is said to be bound by CPU if it has amassed so much work for the GPU, but not able to submit commands to the GPU since the driver is still busy doing stuff on the CPU. In this case, what happens is that the GPU is actually stalling on the CPU! And this is a bad thing. The GPU is meant to be running parallel to the CPU.
6. Can you give examples of how my application would be CPU bound?
If you're familiar with OpenGL, draw calls tend to be quite heavy. There's lot of state validation, etc. that happens in the GL driver that makes draw calls CPU intensive. So, if your application has a lot of draw calls, it may start becoming CPU bound. This is a simple example of how your application may be CPU bound. You may want to use profilers or the right debuggers to actually find out if your application is CPU bound.
7. Ok, I understand all of this. I am a newbie to Computer Graphics, do you advice me to use Vulkan?
It really depends. If you just want to learn Graphics and experiment a bit, Vulkan may not be the right choice for you. However, if you want to know how drivers may work and learn more closely to the hardware, maybe you can try using Vulkan.
8. New is always good right? So shouldn't I not use Vulkan for my production code?
Wait..calm down! Before using a new API, you'd want to profile and find out if you really are CPU bound or maybe having other issues that OpenGL cannot solve. If the answer is yes, then use Vulkan.
9. Why can't OpenGL solve all those problems mentioned in (2).
It does, to some extent. There are proprietary extensions available that have low driver overheads. Multi-threaded command submission is also available to some extent. You may want to check out the following
If none of those help, Vulkan is the right choice for you.
11. What is meant by 'multithreaded-friendly'?
OpenGL was designed when CPUs had one core and multithreaded programming wasn't mainstream. But was time went by, multi-threaded programming and multi-core CPUs started becoming very common and the APIs design couldn't really scale well. There is a provision of creating shared contexts in OpenGL, but the command submission is generally serialized. This is one of the major issues in current day rendering engines that use OpenGL. There's always a single "render thread" that submits all draw calls. To say it in simpler words, OpenGL was never meant to be multithreaded friendly.
12. Why do you say OpenGL is NOT truly Cross-platform.
If you have really written applications that are shipped on Desktop, Embedded and multiple OSes, you'd probably know what I mean. True, OpenGL ES is meant to be a subset of OpenGL. However, there are always a lot of issues you could run into if your application is meant to be supported on multiple platforms. Another major issue is the Window system interfacing. The whole Wgl, EGL, X11 code creates a big mess of #ifdefs! This is another major problem Vulkan is trying to solve. Have one code that runs on multiple platforms with very minimal ifdefs. This is possible via the WSI(Window System Integration). So, these are some of the questions I had before I started learning Vulkan.
I hope this helped you as well. We can start learning more in the coming tutorials. Please leave questions if you feel I can add more details.
In the introduction, I will have more of an FAQ based Q and A section to introduce Vulkan.
1. So, Vulkan is the next OpenGL right?
Vulkan is NOT replacing OpenGL. I repeat, Vulkan is not a replacement for OpenGL. Vulkan is a low level, explicit API that is designed to solve a specific set of problem(s). If, as an application developer, you're not facing those issues, then -- NO, you probably don't need Vulkan.
2. So, what is Vulkan good for?
Good question. Some of the main problems that Vulkan is trying to solve are-
- Having low CPU driver overhead.
- Be more explicit and give better access to hardware.
- Be multithreaded friendly.
- Be truly cross-platform.
- And a few more. The above are the most important ones.
As you may know, OpenGL has been around for quite a while (~24 years as of this writing). It has undergone significant changes, but fundamentally, OpenGL was not designed to solve the above mentioned three problems. GPU and CPU hardware has changed immensely since the first version of OpenGL.
3. What do you mean by 'CPU driver overhead'
The main job of the OpenGL(or any GPU driver software) is to submit commands to the GPU. The GPU is supposed to run parallel to the CPU and the main goal of the driver software is to pick up commands from the application and submit them to the GPU.
4. What is the overhead involved? (3) seems quite simple. Why is it so CPU intensive?
Conceptually, the idea looks simple. However, the driver has to do a LOT of operations in the back. By design, OpenGL was meant as an "easy" API. By "easy", I mean that the application developer need not have to worry a lot. He/She can just call the simple APIs and the driver makes sure things work. Now, with a simple API, the driver has to do a lot of things, namely maintaining certain heuristics about how the application is using resources, making intelligent guesses to provide optimizations, guessing how the buffers would be used by application, doing state validations, allocating and cleaning up of memory and tonnes of other things. All this work tends to create huge bottlenecks on the CPU. So, there could be applications that are bound on the CPU.
5. Ok, I understand that the driver has a lot of work, but what is this "bound by the CPU"?
An application is said to be bound by CPU if it has amassed so much work for the GPU, but not able to submit commands to the GPU since the driver is still busy doing stuff on the CPU. In this case, what happens is that the GPU is actually stalling on the CPU! And this is a bad thing. The GPU is meant to be running parallel to the CPU.
6. Can you give examples of how my application would be CPU bound?
If you're familiar with OpenGL, draw calls tend to be quite heavy. There's lot of state validation, etc. that happens in the GL driver that makes draw calls CPU intensive. So, if your application has a lot of draw calls, it may start becoming CPU bound. This is a simple example of how your application may be CPU bound. You may want to use profilers or the right debuggers to actually find out if your application is CPU bound.
7. Ok, I understand all of this. I am a newbie to Computer Graphics, do you advice me to use Vulkan?
It really depends. If you just want to learn Graphics and experiment a bit, Vulkan may not be the right choice for you. However, if you want to know how drivers may work and learn more closely to the hardware, maybe you can try using Vulkan.
8. New is always good right? So shouldn't I not use Vulkan for my production code?
Wait..calm down! Before using a new API, you'd want to profile and find out if you really are CPU bound or maybe having other issues that OpenGL cannot solve. If the answer is yes, then use Vulkan.
9. Why can't OpenGL solve all those problems mentioned in (2).
It does, to some extent. There are proprietary extensions available that have low driver overheads. Multi-threaded command submission is also available to some extent. You may want to check out the following
If none of those help, Vulkan is the right choice for you.
10. What do you mean by 'more explicit'?
OpenGL, by design, hides many things from the application. This causes application not to be sure of the behavior. Another thing is that different Hardware Vendors may implement certain things a bit differently causing application behavior across different vendors to be slightly unpredictable. Vulkan on the other hand is designed to not have these unpredictability. 11. What is meant by 'multithreaded-friendly'?
OpenGL was designed when CPUs had one core and multithreaded programming wasn't mainstream. But was time went by, multi-threaded programming and multi-core CPUs started becoming very common and the APIs design couldn't really scale well. There is a provision of creating shared contexts in OpenGL, but the command submission is generally serialized. This is one of the major issues in current day rendering engines that use OpenGL. There's always a single "render thread" that submits all draw calls. To say it in simpler words, OpenGL was never meant to be multithreaded friendly.
12. Why do you say OpenGL is NOT truly Cross-platform.
If you have really written applications that are shipped on Desktop, Embedded and multiple OSes, you'd probably know what I mean. True, OpenGL ES is meant to be a subset of OpenGL. However, there are always a lot of issues you could run into if your application is meant to be supported on multiple platforms. Another major issue is the Window system interfacing. The whole Wgl, EGL, X11 code creates a big mess of #ifdefs! This is another major problem Vulkan is trying to solve. Have one code that runs on multiple platforms with very minimal ifdefs. This is possible via the WSI(Window System Integration). So, these are some of the questions I had before I started learning Vulkan.
I hope this helped you as well. We can start learning more in the coming tutorials. Please leave questions if you feel I can add more details.
