What is Vulkan and how does it differ from OpenGL?
Vulkan is the new generation, open standard API for high-efficiency access to graphics and compute on modern GPUs. This ground-up design, previously referred to as the Next Generation OpenGL Initiative, provides applications direct control over GPU acceleration for maximized performance and predictability.
Their page is quite marketese/jargon-heavy, as is the press release… In simple terms, what does Vulkan mean to game developers? (Gabe Newell is quoted as being strongly in favour, without further explanation.)
What exactly is Vulkan's relationship to OpenGL? Its previous name "glNext" (short for "Next Generation OpenGL Initiative") makes it sound like a replacement.
Update: The Vulkan 1.0 spec was released on 16-02-2016.
Translation for people who don't catch the Star Trek drift: *Khronos* and *Vulkan* sound like *Qo'noS* and *Vulcan*; the homeworld planets of the Klingon and Vulcan races. Leonard Nimoy, the actor of Spock (a very popular character) recently died on 2015-02-27, so speculation abounds that the name was a tribute. However, it was coincidental: The *Vulkan* trademark request was filed on 2015-02-19; before Nimoy's death.
@Boreal Vulkan == Volcano in many languages (German, Russian (adjusted for cyr.), etc). So it's Mantle -> Lava -> Vulkan (Volcano) really :)
- 6 years ago
Vulkan is a new API for hardware-accelerated graphics (and general computation) via traditional GPUs. OpenGL will continue to be developed, as it is a higher-level API than Vulkan is intended to be. Originally referred to "glNext," one can infer that Vulkan was likely going to end up being "OpenGL 5," but that the standards body eventually decided that a new name would better coincide with the relatively clean break the API purports to make from existing OpenGL paradigms.
Vulkan's practical advantages to game developers are primarily about control (as in, allowing more of it, potentially allowing for better optimizations at the cost of significantly more up-front work on the developer's part). Specifically:
- The API is oriented around asynchronous generation of command buffers across multiple threads and sequenced processing of those buffers to a command pipeline. This reflects the realities of modern hardware. Most high-profile and/or high-performance software built on OpenGL today implement this kind of behavior themselves; having the API support this itself means that developers need not implement and maintain that framework themselves, or that they can do so with less effort.
- Thread and memory management tasks are left to the application, not the driver, allowing game developers more control over those behaviors and thus potentially more accurate tailoring of those behaviors to their individual game's needs.
- Validation and diagnostics layers can be independently enabled, allowing in theory for better tools integration with the API (something OpenGL itself has suffered from) and disabling of excessive validation, in theory allowing "the graphics on level three" to be that much more performant.
- There's no hard API differential between mobile and desktop versions, which will in theory ease the porting of cross-platform games and if nothing else reduce version-checking headaches that everybody hates.
Vulkan's very C-like / OpenGL-like in superficial structure (the look and feel of the API calls, et cetera. It is, however, better typed (in that not everything is a bare
int; there are relevant typedefs and so on).
It is much lower-level than OpenGL. One can expect a jump in operational setup and complexity between OpenGL and Vulkan as was seen in the D3D9 to D3D10 transition, which exposed a lot more of the under-the-cover details of GPU device operation to the API client. The transition is actually more akin to D3D11 to 12, since D3D12 is itself a very similar API to Vulkan, capability-wise.
It may be worthwhile to point out that Vulkan is basically a highly-iterated version of Mantle: http://community.amd.com/community/amd-blogs/amd-gaming/blog/2015/03/03/one-of-mantles-futures-vulkan The API conventions seem somewhat similar to DSA OpenGL, except with the ubiquitous `gl` prefix replaced with `vk`: http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus
I'd been assuming this would be the case, but hadn't seen any evidence until that link, thanks.
FYI, you'll be able to replace the speculation and guessing with (some) hard fact after Valve's presentation on Thursday and the moratorium on Khronos members revealing more details is (mostly) lifted.
I find the shader bytecode thing slightly amusing, considering there used to be a simple assembly-like language for shaders, and then it was replaced by a complex language (GLSL), and now we're going back to a simple bytecode language.
I thought Vulkan, like Mantle, would stand next to OpenGL for more low-level access, not replace it completely. At least that is what I've read so far. Or will Vulkan cover both low-level and high-level operations?
When you say there is a jump in complexity from OpenGL to Vulkan, are you referring to old-style OpenGL or version 3+? From OpenGL v2 to v3 I already had some fun, so if referring to v3...
@AdrianMaire Vulkan's more complex than any version of OpenGL.
@JoshPetrie When you said that `Thread and memory management tasks are left to the application, not the driver`, I have a question in my mind. Gaming on Linux PC's have less performance due to limited graphics driver supports compared to Windows PCs (correct me if I am wrong). That way, by what you have said, there is no need for a driver and every machine that has graphics card will have the same performance on every game regardless of the OS. Am I right?
You still need drivers, and no I don't think that's a safe assumption to make.
SPIR-V is not a native format. The IR in SPIR-V = "intermediate representation" as in not the final format used on the GPU. That still has to be compiled to some binary format for the GPU. In that sense it is no different than GLSL. You can pre-compile GLSL and you can pre-compile SPIR-V. Both of those have to be per GPU/Driver which usually means it happens on the user's machine. Of course SPIR-V is probably easier to compile but you never know how much after the fact optimizations GPU vendors will apply to try to make their GPUs appear faster. Cutting out dead code for example.
@gman Is there some part of my answer that makes you think I was stating SPIR-V was a native format? (I am not clear what prompted your comment, if it's responding to something directly in my answer or in the subsequent comments, etc?)
@JoshPetrie, yes, your answer says *it means developers can pre-compile to this bytecode as part of a game's asset baking process, rather than having to compile shaders at runtime on an end-user's machine.*. This is false. SPIR-V still has to be compiled on on end-user's machine no different than GLSL. They're just different languages. SPIR-V is lower level, but it still has to be compiled on the user's machine for their specific driver/gpu and it will still be optimized while being compiled making compiling a time consuming task the same as GLSL was.
@gman Ah, I see, thanks. My understanding when I wrote this was that precompilation into the intermediate format would make the final end-user compilation so simple and fast as to effectively take an insignificant amount of time. I guess that's not the case? I'll update my answer when I am no longer on a phone.
@JoshPetrie, it might be faster, especially at first, but drivers will want to remove dead code and apply optimizations so that their GPU appears to run faster than their competitors. The more they optimize the slower compilation will get. The less they optimize the slower optimizable shaders will run.