Khronos launched the Vulkan 1.0 specification on February 16th, 2016 and Khronos members released Vulkan drivers and SDKs on the same day. Below you will find everything you need to come up to speed on Vulkan and to forge ahead and explore whether Vulkan is right for your engine or application.
From the article:
Vulkan is a new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.
Sometimes you really need to explain what it does. Vulkan is rather generic techy name.
It’s a new open API.
It’s closer to the metal than opengl.
It gives more control to coders – eg per thread.
It is more effort for coders.
Benefits? Less CPU bottleneck, greater uylisafion of GPU.
Don’t worry, we’ll soon get Java compiler for Vulkan VM to create Gameboy emulators
Uhhh I would say the biggest advantage is it can be used on all the consoles and PCs whereas DirectX and CUDA are proprietary and can only be used on platforms and hardware controlled by those 2 companies.
I would argue this is the first time since the early 00s that something that could really go toe to toe with DirectX has come out and it will be interesting to see where it leads. This can be run on phones and tablets and consoles and PCs, a chance for truly having “write once use everywhere” and it will be interesting to see if proprietary wins this time.
Vulkan can be used on all those platforms, that does not mean that it will be. All those companies that make platforms and hardware have to actually decide to use it and write/support drivers for it…
You are likely to see it eventually anywhere you would normally see OpenGL supported, just as your likely never going to see it where OpenGL isn’t already supported. It really doesn’t change anything.
I’m not trying to put it down, I think it is great. I just don’t think it really changes much of anything. The advantage you cite really doesn’t exist in reality, or said another way it exists exactly as much as it already does for OpenGL…
That is one of the most 1997 logos I’ve seen. Just look at that swoosh; check out its majesty.
Oh – and you must see the full logo with the industry-standard-teapot*-but-with-attitude https://www.khronos.org/assets/uploads/developers/library/overview/V…
[*] https://en.wikipedia.org/wiki/Utah_teapot
Edited 2016-02-16 19:28 UTC
That logo is amazing!
Every paper I read in grad school used those three models.
Can someone explain to me the benefit of using Vulkan over OpenGL for creating a 3d modelling program? Currently I am working on a 3d modeller which was written in GTK1/OpenGL1 which I have ported to GTK2 and 3, and Opengl 3/4. Is there any benefit to porting to Vulkan outside of speed which would make a port worthwhile?
Considering Intel are only providing Vulkan on 5th & 6th Gen processors (hello obsolescence my £240 3.4GHz i7 4790), that’d only minimise your market. Maybe perhaps best wait until libraries come out that let you target both.
Why do you say that? The source avalible clearly states support back to Sandy Bridge.
See “This directory provides support for the Intel Haswell, Ivy Bridge and Sandy Bridge GPUs” at https://github.com/LunarG/VulkanTools/tree/master/icd/intel
Not fully, Vulkan is only fully compliant with Broadwell and newer.
What are you talking about? Vulcan can be used on ANY processor that supports SSE3 and newer. (VIA C*, AMD Any amd_64 cpu and Intel P4 precsott onwards)
Or do you mean intel graphics? Those are not meant to be used for anything but 2d and limited rendering (and the image quality is still rather poor at that, not even beating a rage128 in 24bit colour)
If you have a dedicated GPU and a processor from 2004 onwards, it supports vulcan.
One nit pick – if you use AMD GPUs on Linux you only have support for the R9. The Vulkan drivers require the AMDGPU kernel driver to work, and right now that only exists for the R9 and newer.
On Windows it is pretty much universal, at least for nvidia and AMD.
OpenGL is a single threaded API with a very heavy handed State Machine. API calls that should simply return with no computaitonal weight often churn in the driver for a while to decide if they will change state. Additionally lots of calls stall the graphics pipeline for state validation.
Vulcan has almost zero validation and expects you to understand your resources and implement your own locking. This allows Vulcan to render two different framebuffers in the same memory space in different threads while uploading resources in a third. In general the API is so close to the metal it is only for engine developers, but who knows we might actually see a light weight lib written on-top of it that will make it fairly easy to code high performance graphics on it.
Additionally, Vulcan allows for per-compiled shaders to be uploaded directly to the card. So, you no longer have to code in GLSL if you prefer a different shading language.
No. Just like with Direct3D 12, the benefits only appear if you completely redesign how you manage your resources and transfer data to/from the GPU.
Both Khronos and Microsoft recommend that you stay with Direct3D 11 or OpenGL if your application isn’t all about performance. Essentially the improved speed comes from removing the guarantee that what you see as an application is always fully synchronized with the GPU.
In OpenGL, if you use a texture just after you uploaded it, the system guarantees that the GPU will wait for the upload to finish before running the shader. With Vulkan it is your job to insert the proper synchronization primitives that ensures this is true.
The catch is that such kind of multi-threading is hard, and the overhead from the in-order pipeline in OpenGL/Direct3D is a price worth paying for probably the majority of applications. So you should only switch to Vulkan/D3D12 if the following two things are true:
1) you absolutely must get the last 20% performance out of the CPU and GPU
2) you are willing to invest in the significantly increased complexity required to reach this goal