Some people said that Vulkan is more like modern GPU architecture, compared to OpenGL, which is less like modern GPU architecture. What is the biggest difference between Vulkan and OpenGL that arises because of this? People also said that Vulkan is very verbose. What books do you recommend for learning Vulkan? What would be the biggest benefit of migrating to Vulkan?
taby said:
Some people said that Vulkan is more like modern GPU architecture, compared to OpenGL, which is less like modern GPU architecture.
OpenGL is very abstract and high level, Vulkan is close to the metal / low level.
taby said:
What is the biggest difference between Vulkan and OpenGL that arises because of this?
10 times more code at least. Even the simplest things are tedious to set up. Much more details need to be handled. Some examples…
Creating device context and swapchain initialization is > 1000 lines of code i think.
You need to handle synchronization yourself, e.g. having semaphores to know when rendering passes are done and ready to display.
Or memory barriers if you write to a resource, but need to read from the same resource in a later dispatch.
Or resource transitions, e.g. turning compressed framebuffer into readable textures (i guess).
You need to handle memory allocation yourself, including specification of certain memory types. (visible to host, device only, etc.)
If you want to upload a texture, you first need to create a staging buffer, then copy the image data to that buffer, then copy from the slow buffer to final device memory.
You can not issue commands like with OpenGL. Instead you need a command buffer for everything.
You create such buffer, then record commands to the buffer (e.g. all the stuff needed to upload a texture, or rendering some triangles, or compute shader dispatches, etc.).
After that you upload the command buffer to GPU and execute it from there.
That's actually a big performance win, because the command buffer is the new ‘draw call’, but it can contain many rendering and compute dispatches, not just one.
Thus, in theory, you can implement a whole gfx engine in just one draw call ('GPU driven rendering'). And you can even keep the commands on GPU and do not need to upload them each frame.
You can also generate multiple such command buffers on multiple CPU threads.
Those things are the biggest benefit from my perspective. Made my stuff two times faster than former high level APIs.
Besides you have access to new GPU features (ray tracing, mesh shaders, variable rate shading).
taby said:
People also said that Vulkan is very verbose.
Yeah, it has validation which you can use in debug mode. If the driver detects you do something wrong, you get good feedback in form of error message and object pointer.
That's actually the only point where VK has an advantage over OpenGL regarding ease of use.
taby said:
What books do you recommend for learning Vulkan?
If you really like graphics programming, check it out. But getting started is much harder.
Also, due to everything being so tedious to set up, it's not really useful to try out some ideas quickly. It's about performance, not creativity.
taby said:
I think that I'll skip Vulkan.
There is a middleground too. Crytek uses VK for ray tracing, but still DX11 for all the rest, for example.
And DX12 is generally less complex, due to missing out on mobile GPUs. (Though, VK meanwhile has such ‘easy mode’ too, but i guess tutorials do not really cover that yet.)
But yeah, without a really good reason, i would not want to go low level either.
Next year i should finally get started with rendering, than i shall see how much pain it really is… : )
JoeJ said:
taby said:
I think that I'll skip Vulkan.There is a middleground too. Crytek uses VK for ray tracing, but still DX11 for all the rest, for example.
And DX12 is generally less complex, due to missing out on mobile GPUs. (Though, VK meanwhile has such ‘easy mode’ too, but i guess tutorials do not really cover that yet.)But yeah, without a really good reason, i would not want to go low level either.
Next year i should finally get started with rendering, than i shall see how much pain it really is… : )
I wouldnt say DX12 is less complex you are dealing with the same concepts the functions you use are just different, you still have to do all the management yourself. The only real benefit is you have no extensions to check for but this has been this way since DX10. You have to deal with DXGI<Class><Number> in DX12 so its not easier. What does really help in DX12 is that you can use
Whilst its not easy to write with these render APIs they are not impossible to grasp, the hard parts are that you need to understand the concepts invovled like descriptor handles and command queues. And you can start all of this with a single command queue and command buffer which makes it look alot like DX11 or OpenGL to begin with. The way you dispatch the command buffer is just different, this was easier coming from DX11 I think since you are already dealing with the device context to do everything.
All resources in these API have become immutable, which means you create them and thats it you can't change them anymore, again DX11 had this concept already for certain things which makes the shift easier.
The major thing is you have to probably also switch to bindless rendering if you start using these APIs because it will cut down on a lot of the descriptor management. It simplifies a lot of the things you have to do if the shader can just index into a data array to find the information you need for that drawcall. (this is severly trivialised what bindless is btw).
NightCreature83 said:
I wouldnt say DX12 is less complex
Yeah, difference is surely small. But DX12 has no Render Passes, which is soemthing at least. And is aw they make swapchain with 10 lines of code, which made me envy. : )
NightCreature83 said:
The major thing is you have to probably also switch to bindless rendering if you start using these APIs because it will cut down on a lot of the descriptor management. It simplifies a lot of the things you have to do if the shader can just index into a data array to find the information you need for that drawcall. (this is severly trivialised what bindless is btw).
That's what i want, but didn't try to learn about yet.
I guess the main cost is that we get some data from Vram instead from on chip constant ram?
But still, i do not like the traditional approach of setting up uniforms, the use some shader, and this a thousand times. I want something more general instead.
JoeJ said:
NightCreature83 said:
I wouldnt say DX12 is less complexYeah, difference is surely small. But DX12 has no Render Passes, which is soemthing at least. And is aw they make swapchain with 10 lines of code, which made me envy. : )
NightCreature83 said:
The major thing is you have to probably also switch to bindless rendering if you start using these APIs because it will cut down on a lot of the descriptor management. It simplifies a lot of the things you have to do if the shader can just index into a data array to find the information you need for that drawcall. (this is severly trivialised what bindless is btw).That's what i want, but didn't try to learn about yet.
I guess the main cost is that we get some data from Vram instead from on chip constant ram?
But still, i do not like the traditional approach of setting up uniforms, the use some shader, and this a thousand times. I want something more general instead.
Its much more painful to do this in DX12 and Vulkan your copy descriptor is the most used function on the API if you do not go bindless, because how you load the resource is not neccesarily how you use it and as such you have to place the descriptors inthe order the GPU expects this drawcall to use them.
From what I am reading of Vulkan its not all that different from DX12 at all, the tutorial from the main page is just very very carefull and checks everything, you should technically write DX12 in the same way. It's just that most samples dont show this because I think they are not fully written for the novice but for someone who kinda knows DX already and just needs to see whats different. I remember the old DX9 tutorials they were written like the vulkan ones are now.
NightCreature83 said:
From what I am reading of Vulkan its not all that different from DX12 at all, the tutorial from the main page is just very very carefull and checks everything, you should technically write DX12 in the same way. It's just that most samples dont show this because I think they are not fully written for the novice but for someone who kinda knows DX already and just needs to see whats different. I remember the old DX9 tutorials they were written like the vulkan ones are now.
What i've seen was not tutorials about error checking, but source code from tech demos. It looked like DX12 has some simplified way to set up the swapchain, maybe optional to a detailed way. VK attempts to add such convenience features too.
But i fully agree VK and DX12 is more or less the same thing.
I notice the problem of managing descriptors is often discussed, but idk the differences across APIs regarding this.
The most important differences i came across are DX12 Execute Indirect, which VK lacks, and DX12 Split Barriers, which VK lacks too. The VK workarounds needed to get those features are not really ideal it seems.
On the other hand VK is (or was) ahead with things like subgroup operations. They were core much earlier than with DX, and it exposed more features. Maybe the latest DX shader model catched up already.
However, both APIs lack a way of proper conditional command buffer/list execution. You can skip over draws, but you can not skip over memory barriers.
That's a pity, because you get no optimized coarse control flow on GPU. In my case this means many dispatches of zero work, and after that executing memory barriers for no reason, which has quite a cost.
Mantle had this feature. You could even run commands in a loop, e.g. until error of an iterative solve is small enough, then break out.
I'm sure every modern GPU could do this now technically, and i criticize both DX12 and VK seem already stuck and do not really evolve beyond adding the latest hyped features. >:(
Sadly the days of GPU rant are far from over for me…
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement