Vulkan Tutorial(av.dfki.de)
av.dfki.de
Vulkan Tutorial
http://av.dfki.de/~jhenriques/development.html
67 コメント
In support of this.
Dereferencing a NULL pointer is undefined behaviour.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
C Standard http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 6.5.3.2 Address and indirection operators ... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. ... Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
C Standard http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 6.5.3.2 Address and indirection operators ... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. ... Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
I've always wondered how Vulkan is bootstrapped and its drawing surface attached to a window. Now I know.
I would assume that the code for Linux and Android is similar.
I would assume that the code for Linux and Android is similar.
They weren't kidding when they were saying it's a lot more work.
This looks like a great tutorial; it builds up a "Hello Triangle" using a nice balance of English and C.
I think you mean C++.
I don't see any C++ there, besides a file extension (I might be wrong)
He allocates memory with new/delete and passes arguments with references among other things.
Ah you're absolutely right
Still there are some C quirks, search for "This extension adds three new functions" and see the code block above
Still there are some C quirks, search for "This extension adds three new functions" and see the code block above
what is the current status with driver support for vulkan? are they being rolled out steadily at this point? and does anyone have an opinion on how quickly we will see vulkan drivers become reliable and ubiquitous?
also, check out this awesome demo of DOOM using vulkan. https://www.youtube.com/watch?v=0y3LaLJoo0s
also, check out this awesome demo of DOOM using vulkan. https://www.youtube.com/watch?v=0y3LaLJoo0s
*(void **)&vkCreateDebugReportCallbackEXT = vkGetInstanceProcAddr( ... );
Is there a cleaner/more idiomatic way to do this?
I'm afraid this is the C idiom for assigning a void pointer to a function pointer:
I'm afraid this is the C idiom for assigning a void pointer to a function pointer:
*(void **) &fptr = getvoidptr();
warning: ISO C forbids assignment between function pointer and 'void *'
PFN_vkCreateDebugReportCallbackEXT dbgCreateDebugReportCallback = (PFN_vkCreateDebugReportCallbackEXT)vkGetInstanceProcAddr(instance, "vkCreateDebugReportCallbackEXT");
Interesting, but I'd start with a Linux program for educational purposes. It wouldn't assume one must have Windows to run it.
> First things first, let me just warn you that this is not a beginners tutorial to rendering APIs. I assume you have some experience with something like OpenGL or DirectX and you are here just to get to know the particularities of Vulkan.
Is there some book / tutorial that both introduces rendering APIs to beginners and is using Vulkan for it at the same time?
> First things first, let me just warn you that this is not a beginners tutorial to rendering APIs. I assume you have some experience with something like OpenGL or DirectX and you are here just to get to know the particularities of Vulkan.
Is there some book / tutorial that both introduces rendering APIs to beginners and is using Vulkan for it at the same time?
There might be more game devs using Windows than Linux, just due to market share, so I'd say Windows was the right choice here.
I think educational materials should have different considerations than just market share. But that's my personal opinion.
This is a strange thing to say.
Educational materials are of the most value when they reach their largest relevant audience.
In this case, the largest relevant audience for this kind of thing at the moment is probably game developers, and most of them target Windows in their work.
Are you suggesting this material should have been developed in a way that is less relevant to that largest audience? I don't see how that would be a good idea.
Perhaps you are getting tripped up on the phrase "market share", thinking only of it in a commercial context, when it simply meant targeting the largest segment of users who will find this useful.
Educational materials are of the most value when they reach their largest relevant audience.
In this case, the largest relevant audience for this kind of thing at the moment is probably game developers, and most of them target Windows in their work.
Are you suggesting this material should have been developed in a way that is less relevant to that largest audience? I don't see how that would be a good idea.
Perhaps you are getting tripped up on the phrase "market share", thinking only of it in a commercial context, when it simply meant targeting the largest segment of users who will find this useful.
> This is a strange thing to say.
That's a normal thing to say. One shouldn't assume student has to pay a tax to learn (i.e. Windows tax). It's inappropriate.
That's a normal thing to say. One shouldn't assume student has to pay a tax to learn (i.e. Windows tax). It's inappropriate.
One shouldn't assume that they must. But, one can look at the stats to observe that they have. Linux is still sitting at 0.9% on the Steam hardware survey. By trying to be inclusive in theory, you would be excluding 99% of the audience in practice.
>One shouldn't assume that they must. But, one can look at the stats to observe that they have.
You have stats about students? Where is it published? You can't use Steam for measuring education metrics.
Anyway, apparently the author wanted to provide tutorials for different OSes. My point was that he could focus on Linux first, and that would have been a proper educational choice as I explained above.
You have stats about students? Where is it published? You can't use Steam for measuring education metrics.
Anyway, apparently the author wanted to provide tutorials for different OSes. My point was that he could focus on Linux first, and that would have been a proper educational choice as I explained above.
> most of them target Windows in their work
Windows? I would have guessed iOS as the top target platform.
Windows? I would have guessed iOS as the top target platform.
iOS doesn't support Vulkan.
That doesn't seem relevant to the argument about largest game development target platform.
Vulkan is brand new it's going to take a while to filter down. This is the first "advanced" level tutorial I've even seen for it. And it doesn't even talk about rendering with Vulkan, which is way more complicated than just using OpenGL4 (and requires an advanced knowledge of OpenGL or another modern GL). Let alone doing Vulkan specific rendering techniques, which are still being explored.
OpenGL is like the C std/runtime library. Vulkan is like calling the kernel functions directly without wrapping code.
OpenGL is like the C std/runtime library. Vulkan is like calling the kernel functions directly without wrapping code.
Gonna be honest, was hoping for an into for a Star Trek languange.
I think that is spelt "Vulcan".
What is Vulkan and why are we programming in Win32 in 2016?
The take away for me is that vulkan is similar to opengl. Mindlessly complex APIs just to play around with basic stuff. Graphics really doesn't need to be this complicated :/
With all due respect, you're definitely not the target market for Vulkan. It's an incredibly low level abstraction layer over GPUs intended to allow rendering engine developers to control the intricate details of the pipeline. For something simple, you'll want to use a game engine like Unity or Unreal, which build on top of this low level stuff to build nice, high level abstractions.
I wander if mass adoption of Vulkan for engine development would initiate "gentrification" - I mean, currently, engine devs enjoy working with OpenGL (or D3D), and there is a big chance many people simply won't enjoy using Vulkan so they won't use it or just leave the field altogether. I suspect using Vulkan will be comfortable for GPU hardware people (hence different demographic).
> currently, engine devs enjoy working with OpenGL (or D3D)
Where did you get that idea? I almost only ever hear bad things about them both. Bloated APIs with even more bloated drivers. Layers upon layers of hacks and fixes.
Presumably, Vulkan will enable the emergence of slim, nice, rapidly evolving apis built on top of them, giving developers much better tools to build apps or engines with.
Where did you get that idea? I almost only ever hear bad things about them both. Bloated APIs with even more bloated drivers. Layers upon layers of hacks and fixes.
Presumably, Vulkan will enable the emergence of slim, nice, rapidly evolving apis built on top of them, giving developers much better tools to build apps or engines with.
> giving developers much better tools to build apps or engines with.
oh, that's the different [good] thing.
I was talking about abstraction level/layer - I doubt those who enjoy (feel comfortable) working at the OpenGL or D3D layer will be the same contingent who will enjoy using Vulkan.
But as you said, if some other API-s emerge on top of Vulkan, better than OpenGL, that would be great of course.
oh, that's the different [good] thing.
I was talking about abstraction level/layer - I doubt those who enjoy (feel comfortable) working at the OpenGL or D3D layer will be the same contingent who will enjoy using Vulkan.
But as you said, if some other API-s emerge on top of Vulkan, better than OpenGL, that would be great of course.
Vulkan has practically no incidental complexity. The API is complex because it maps directly to a very complex system of hardware. Any simplification would make it worse.
If you want a simple way to draw graphics without all the complexity, you don't want a graphics API, you want a game engine.
If you want a simple way to draw graphics without all the complexity, you don't want a graphics API, you want a game engine.
It's possible to make a less-complex low-level graphics API. Apple's Metal framework manages to be much easier to use (though still a bit of work to set up).
I fully agree that Metal is a much nicer API than Vulkan or OpenGL, but IMHO it isn't really a low-level API in the sense of D3D12 or Vulkan. While Metal also has pipeline-state-objects, command-buffers and some other 'explicit features' like the other two APIs, the entire resource binding is very high level, more like in D3D11 (which IMHO is a good thing, because that is exactly the part that makes D3D12 and Vulkan so complex, while providing only few advantages over the more traditional resource binding).
Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. Most big games that have been released with a D3D12 renderer so far, don't run better than with the D3D11 renderer. Metal mostly shines on iOS, where it is dramatically faster then OpenGLES, but it isn't dramatically better on OSX (at least on the Intel GPU configs I'm testing on).
Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. Most big games that have been released with a D3D12 renderer so far, don't run better than with the D3D11 renderer. Metal mostly shines on iOS, where it is dramatically faster then OpenGLES, but it isn't dramatically better on OSX (at least on the Intel GPU configs I'm testing on).
> Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games.
The main reason for revamped APIs like Vulkan are not performance enhancements but reducing driver complexity and give better diagnostics to developers. Also huge amounts of current generation GPU drivers are heuristics for increasing applications' performance but more importantly to make inherently broken applications (that violate the API contract) still work.
At a recent Khronos event one of the Vulkan engineers of Team Red put it in the following words: "OpenGL and Direct3D-11 and before have the architectural legacy of GPUs as they were 10, 20 years ago. Since then GPUs went that way, while OpenGL and <=D3D-11 went another one. D3D-12 and Vulkan are APIs designed for the modern GPU way, and in 20 years we'll likely see another way of GPUs and APIs".
The main reason for revamped APIs like Vulkan are not performance enhancements but reducing driver complexity and give better diagnostics to developers. Also huge amounts of current generation GPU drivers are heuristics for increasing applications' performance but more importantly to make inherently broken applications (that violate the API contract) still work.
At a recent Khronos event one of the Vulkan engineers of Team Red put it in the following words: "OpenGL and Direct3D-11 and before have the architectural legacy of GPUs as they were 10, 20 years ago. Since then GPUs went that way, while OpenGL and <=D3D-11 went another one. D3D-12 and Vulkan are APIs designed for the modern GPU way, and in 20 years we'll likely see another way of GPUs and APIs".
I know driver complexity is a common point for Vulcan, but given that opengl and direct3d are here to stay, aren't the drivers going to get strictly more complex due to it?
I imagine the drivers could just support Vulkan, and the OS could provide a library that implements OpenGL and D3D on top of Vulkan. That way only one implementation of OpenGL would be needed, and it could live outside of the driver.
Good point. That would be particularly neat if the OpenGL/D3D implementations became vendor-independent.
This aspect is two-fold (at least). Yes, it's on the roadmap to implement OpenGL on Vulkan and probably also legacy-D3D on top of D3D-12.
But what's more important is, that all the complexity of OpenGL and legacy-D3D drivers make it very difficult to hit the fast codepaths of the driver.
And OpenGL has the problem that one cannot effectively queue drawing commands from several threads; not to be confused with the (ill) attempt to render from several threads at the same time. We're just talking about the preparation steps here, i.e. traversing the scene, visiting each element sorting them, and one drawing order is determined submitting them into a queue that then can be batched for drawing. With Vulkan one can utilize the multiple CPU cores we have these days: Each core may collect a different aspect of a scene into a different queue.
But what's more important is, that all the complexity of OpenGL and legacy-D3D drivers make it very difficult to hit the fast codepaths of the driver.
And OpenGL has the problem that one cannot effectively queue drawing commands from several threads; not to be confused with the (ill) attempt to render from several threads at the same time. We're just talking about the preparation steps here, i.e. traversing the scene, visiting each element sorting them, and one drawing order is determined submitting them into a queue that then can be batched for drawing. With Vulkan one can utilize the multiple CPU cores we have these days: Each core may collect a different aspect of a scene into a different queue.
Surprisingly, resource binding is the key to performance both on CPU and GPU. The method of binding resources to some "slots" (registers/handles/etc) while being easy to understand is not present in modern hardware. There used to be actual registers for textures/samplers/buffers (well, I don't recall if there had been any hardware with buffers, but there had been just float4 regs to get non-texture data into the shaders) but not any more.
Emulating these in software is expensive as you are essentially running a multi-process application, where every process gets parameters from the global state. You can either run it sequentially (very slow) or make a copy of the state for each process (generally slow, but there are tricks like fragmenting the state and only copying the changed fragments).
I suspect the reason the DX12/Vulkan games are not showing much improvement in performance is that they share most of the code with the legacy DX11/OpenGL and keep emulating the global state for the new API.
Emulating these in software is expensive as you are essentially running a multi-process application, where every process gets parameters from the global state. You can either run it sequentially (very slow) or make a copy of the state for each process (generally slow, but there are tricks like fragmenting the state and only copying the changed fragments).
I suspect the reason the DX12/Vulkan games are not showing much improvement in performance is that they share most of the code with the legacy DX11/OpenGL and keep emulating the global state for the new API.
Depends probably on the games. I can see games like the recently released Stellaris [1] or Star Ruler 2 [2] with it's tens of thousands of spaceships or similar gain the most thanks to the new API's, and it should possibly enable developers to implement things that were previously not feasable because of the draw calls.
[1] https://www.paradoxplaza.com/stellaris
[2] https://www.youtube.com/watch?v=6ChMEMQxQLw
[1] https://www.paradoxplaza.com/stellaris
[2] https://www.youtube.com/watch?v=6ChMEMQxQLw
Don't forget Ashes of the Singularity! http://www.legitreviews.com/ashes-singularity-dx12-benchmark...
DX12 makes AMD cards work really well (thanks to async stuff) and allows AMD+nVidia multi-GPU.
DX12 makes AMD cards work really well (thanks to async stuff) and allows AMD+nVidia multi-GPU.
Yes, totally forgot that game. Really a good showcase of what's possible.
Yes, AMD profits probably the most from the new API's, the CPU's from them get also a good boost because the kind of single threaded-ness of DX11 [1] hurt them. For example, Hitman with DX11 on a AMD FX 8370 and GTX 980 Ti achieves only 41.5 fps while a Intel 6700k reaches 72.5 fps. With DX12 the same AMD system achieves 65.2 fps (Intel 68.3).[2]
[1] http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_...
[2] https://translate.google.de/translate?hl=de?sl=auto&sl=auto&...
Yes, AMD profits probably the most from the new API's, the CPU's from them get also a good boost because the kind of single threaded-ness of DX11 [1] hurt them. For example, Hitman with DX11 on a AMD FX 8370 and GTX 980 Ti achieves only 41.5 fps while a Intel 6700k reaches 72.5 fps. With DX12 the same AMD system achieves 65.2 fps (Intel 68.3).[2]
[1] http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_...
[2] https://translate.google.de/translate?hl=de?sl=auto&sl=auto&...
I'd compare performance gains of Vulkan with OpenGL, not with DX11.
Why? OpenGL is hardly relevant on the desktop. It lost to D3D and everyone knows it. Besides CAD-users few would notice if it stopped working. It should be compared with Dx11 and Dx12 which are the competitors.
The new DOOM uses OpenGL! And it will receive Vulkan support in a patch "soon".
Also, there are platforms other than Windows. All the games ported to OS X and Linux use OpenGL.
Also, there are platforms other than Windows. All the games ported to OS X and Linux use OpenGL.
I used to be a Linux gamer, so I know. OpenGL (and Mac/Linux) still lost. That's just how it is. Now that Vulkan is out, non-Windows gaming has a second chance. We can stop pretending OpenGL matters now.
If it "lost", why did Valve port their games to it & encourage others to port their stuff as well?
Oh, also, pretty much all mobile gaming is OpenGL ES. Also there's WebGL!
Oh, also, pretty much all mobile gaming is OpenGL ES. Also there's WebGL!
Because they are afraid of being left out of Windows when everyone starts making use of Windows Store and they lose their STEAM margins.
OpenGL ES on iOS is for compatibility purposes nowadays, as presented at WWDC 2015, all new features are on Metal.
WebGL still under delivers on mobile devices, only the most expensive devices are able to render something without chocking.
On the desktop is basically used for web site animations and 3D viewers, VRML style.
OpenGL ES on iOS is for compatibility purposes nowadays, as presented at WWDC 2015, all new features are on Metal.
WebGL still under delivers on mobile devices, only the most expensive devices are able to render something without chocking.
On the desktop is basically used for web site animations and 3D viewers, VRML style.
To all the above - Vulkan is a next iteration of open API, not of MS lock-in. All this "lost" or not is irrelevant. Try using DX anywhere outside of MS systems, and then come back and propose using it if you succeed.
I had a look at a Metal tutorial [1], which does the same initialization as the Vulkan tutorial. Indeed, it has similar concept, but is also simpler (partly because it is written in Swift, not C++).
I wonder if anyone has written a wrapper, which would be at the same level as Metal, but run on top of Metal and Vulkan. That would be something I'd like to use!
I still think Vulkan is great. Now, we need to start building libraries on top of it. The nice thing about very low-level APIs is that it is possible to write higher-level APIs on top of them. The opposite isn't really possible.
[1] https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swi...
I wonder if anyone has written a wrapper, which would be at the same level as Metal, but run on top of Metal and Vulkan. That would be something I'd like to use!
I still think Vulkan is great. Now, we need to start building libraries on top of it. The nice thing about very low-level APIs is that it is possible to write higher-level APIs on top of them. The opposite isn't really possible.
[1] https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swi...
The gfx-rs library for Rust is actually targeting exactly that, although they aren't there yet.
It's very low level. Khronos noted, that they didn't have time / resources to create a higher level API (on top of Vulkan) that would at least match the level of OpenGL in usability (but would avoid its downsides like stateful nature). Hopefully someone will make such higher level library. Engines can't fill that role - they are too high level and specialized already. So that middle layer is still missing.
Before vulkan you were on the mercy of Nvidia and Ati to literally rewrite your shaders behind the scenes to get good performance. Ati were notoriously bad at this which lead to Nvidia winning big couple of generations in a row, despite having a modest lead at best in tech.
AMD weren't notoriously bad at it, they were pretty much unwilling to do it, whereas nvidia are more than happy to do it
Obligatory "Should I switch to #Vulkan?" chart:
https://twitter.com/renderpipeline/status/699501481632886786
https://twitter.com/renderpipeline/status/699501481632886786
This chart isn't helpful at present, because OpenGL isn't a proper alternative.
The chart literally is about deciding whether OpenGL is a proper alternative. Maybe you could add some substance to your statement?
Because it assumes the idea that OpenGL is for higher level, and Vulkan is for lower level. However what's needed for higher level is some stateless API based on Vulkan, and that's currently simply missing.
Oh, the niceties of C Windows programming
I wonder how anyone got anything done in that time. Really
And the wrong (but very common) type of Hungarian Notation - http://www.joelonsoftware.com/articles/Wrong.html
Edit: I don't get the downvotes
I wonder how anyone got anything done in that time. Really
And the wrong (but very common) type of Hungarian Notation - http://www.joelonsoftware.com/articles/Wrong.html
Edit: I don't get the downvotes
I guess you're being downvoted because there's about 60 lines of Win32 code -- the rest is the verbose Vulkan API, which is the same on every platform.
I have also created the helper function assert() that does what you would expect ...
Just call abort [1]. Or better yet, just call assert [2].
Then, in favour of using the Vulcan SDK, it continues:
just need to copy vulkan.h and vk_platform.h to our application folder ... [i]f you run this piece of code you will notice that you might have found no layer... This is because, at leat on my system, the loader could not find any layer. To get some validation layers we need the SDK ... [w]hat I found out during the process of trying to figure out if you needed the SDK or not is that you only need the .json and the .dll of the layer you want somewhere on your project folder and then you can setup the VK_LAYER_PATH environment variable to the path to the folder with those files.
This is not how you build reliable software. Use the IDE/SDK/standard libraries already! You'll be done quicker. With less undefined behaviour.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ab...
[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/ass...