Frequently Asked Questions
Select a topic below to see related questions and answers.
- Khronos APIs
- Validation Layers
- Vulkan Applications
- Vulkan Features
- Vulkan Loader
- Vulkan Name
- Vulkan Tools
From an external point of view, the biggest difference has to do with the platforms and the hardware that they support. DirectX 12 was designed for just a few target hardware devices. It runs on only one operating system, whereas Vulkan supports hardware from 10s of companies and supports a much broader range of platforms. There is a bit higher level of abstraction in Vulkan that accommodates that increased affordability. The abstraction is a good thing because it enables affordability, while providing the same performance and usability you get from DirectX 12.
The Khronos EGL team developed Windows System Integration (WSI) extensions for Vulkan. The WSI extensions are essentially the new generation EGL to Vulkan. This may be an oversimplification, but EGL is intended to play the same role for Vulkan that it plays in the OpenGL ES world. The EGL group has historically defined the context creation and Windows system interface for OpenGL ES.
In Vulkan, it was decided not to separate WSI from the API quite so strictly. Instead, WSI is defined by a series of extensions to Vulkan, rather than a separate API. Khronos had extensive conversations with Google and Android and other platform owners in order to ensure the mechanism works well across multiple APIs, including Windows. The bottom line is that there is no EGL for Vulkan, rather WSI in Vulkan is handled by extensions.
The glTF file format supports transmission of 3D assets between applications and across the network. It was originally designed with WebGL and OpenGL ES in mind. Because of this, certain design elements require modification for Vulkan applications. With some work, you can manually modify a glTF file and parse it to load in Vulkan. Future glTF specs are being developed for better compatibility with the Vulkan API.
If your application is interacting with graphics and displaying your results, then doing it all in Vulkan is probably easier and more suitable. But if it’s a more scientific application, then OpenCL is more appropriate. OpenCL has more focus on things like type precision requirements than Vulkan does with its foundation in graphics.
The OpenCL working group has started to discuss Vulkan interoperability, but it is not yet available. There is interoperability with OpenGL and DirectX, so supporting Vulkan would make sense.
It is certainly feasible. There are rumors of projects for running OpenGL on top of Vulkan. However, issues with accessing all the hardware features exist when writing an OpenGL driver straight to the metal. You can obtain comparable performance because Vulkan is at that level, but you would duplicate all the functionality that has evolved inside the major IHVs over the years.
If you’re really new to 3D graphics, OpenGL or one of the other traditional APIs is probably the best place to start learning. In the future, Vulkan’s middleware layer could evolve to potentially provide some interesting learning platforms.
If your application is well-tuned and GPU-bound, you may notice some reduction in CPU power. The CPU may be idle more often, but there won’t be a graphics difference if the application is already GPU-bound. If you get many CPU cycles back, you can explore enhancing rendering using some offline CPU techniques outside the rendering pipeline using a combination of CPU and GPU work to get better results.
In OpenGL, the only choice for writing shaders is to use GLSL and pass the GLSL into the driver. In Vulkan, you can also write in GLSL and use an offline tool chain to translate that to SPIR-V (standard Vulkan only accepts SPIR-V).
There are plenty of other choices, and many people are likely to experiment with different languages and different kinds of tool chains, middleware, and game engines to generate the SPIR-V that goes into the driver. Some can be linked directly into an application, so you don’t have to rely solely on offline support. We call this off-driver support, and you can do it online by using a side tool in real-time. Note that it isn’t part of the core Vulkan drivers stack.
NVIDIA has mixed OpenGL and Vulkan rendering and published the extension that allows this. One of the first extensions is a limited form of interoperability where you can synchronize between an OpenGL context and a Vulkan cue and additionally copy image content from Vulkan to OpenGL. Interoperability is certainly a technical possibility that will require additional extensions in the future.
The initial goal of Vulkan 1.0 is to address the functionality of current GPUs and current drivers. So hardware capabilities are stressed as opposed to middleware. High quality text rendering (anything involving fonts) is out of scope for this level of activity. Vulkan is ideal for layered implementations and layered APIs that would run on top of Vulkan.
Vulkan does not contain a normative reference to any high-level language specification. The only requirement is the ability to accept shaders in the SPIR-V format. For the convenience of the developers, an extension to GLSL was defined to allow it to generate Vulkan-compatible SPIR-V.
There is no barrier for other methods of generating valid SPIR-V. The SDK includes tools that you can use to validate whether a SPIR-V program is legal for Vulkan and should be accepted by a Vulkan implementation.
There is currently no existing OpenGL abstraction layer that sits on top of Vulkan. For now, the question should simply be “Should I port my existing application to Vulkan?”
It depends if you want to or if you feel you need to. OpenGL will still continue to be supported on most of the platforms Vulkan is available on. However, if your OpenGL application is CPU limited or bandwidth limited, it might benefit from being ported to Vulkan.
Vulkan was created as the result for a need for a new generation GPU API. GPUs are increasingly programmable and compute capable, plus platforms are becoming mobile, memory-unified, and multi-core. GPUs will accelerate graphics and compute across diverse platforms. Hence there was a need for flexibility and portability.
As a result, the Vulkan API is Explicit (opens up the high-level driver abstraction to give direct, low-level GPU control), Streamlined (faster performance, lower overhead, less latency), and Portable (cloud, desktop, console, mobile, and embedded).
To gain the benefits that the Vulkan API provides, more work and responsibility is put into the application. Not every developer or application will need to make that investment. For many situations, OpenGL will remain the most effective API. If your application isn’t CPU bound, you don’t put a premium on avoiding hitches, and you won’t do whatever it takes to squeeze out maximum performance, then OpenGL is still a good choice.
Khronos is hoping glslang will be the standard, although the community is welcome to build on that. It’s an open-source project, and it implements the new version of GLSL that supports the Vulkan features.
The Khronos Github includes a gslang folder. It’s the official reference Khronos validation layer to validate that the GLSL you’re using conforms to the specification. You can translate or modify it for Vulkan GLSL into SPIR-V, then send that into the drivers for the different platform.
Anyone is welcome to contribute to the project. The lead author, John Kessenich, is an active member of the working group, and he is also the editor of the GLSL specification. Khronos endorses glslang as an ESSL/GLSL validator. Khronos does not guarantee that it is bug free, but does guarantee to expend effort to fix it if there are issues. You are certainly allowed to create your own GLSL/SPIR-V compiler, but Khronos would rather fix any bugs in glslang.
That is certainly a technical possibility. The issue is translating DirectX shader code that is post-compiled code into SPIR-V for consumption. The other option is to compile directly from the HLSL, if that’s how you’re generating your binary blobs, which may be typical in the more modern DirectX APIs. Either path will work.
That is the goal of the SPIR-V and Vulkan relationship. Khronos has written the most rigorous specification possible for SPIR-V, and any issues should be reported to the SPIR-V project.
The one caveat is that Vulkan does not specify error behavior. If you write a SPIR-V shader that does not follow the SPIR-V specification, different implementations may have different behaviors.
If your SPIR-V passes the SPIR-V validator but behaves differently on different implementations, let Khronos know.
There are feature capability support bits in SPIR-V, so if you have a shader that works on one implementation that supports some capabilities and you run it on an implementation that does not support those capabilities, that’s not going to work. But otherwise the intent is that things are portable and that there are less implementation variations in SPIR-V consumers than there has been in GLSL compilers.
An SDK is not required. You can find the different elements, which are open source and free from multiple repositories, then build them and compile them together.
Bringing them together in one place, binaries already built, and providing a forum where questions can be asked is the benefit of getting the SDK from vulkan.lunarg.com.
Not that we are aware of.
The SDK includes the official Khronos loader (libvulkan.so), which was developed by LunarG.
The standard way on Linux for the loader to find a driver is for the driver vendor to provide a manifest file that the driver vendor installs in one of these three locations:
An environment variable (VK_ICD_FILENAMES) can be used to specify an alternative path, which over rides the above three locations.
For more information, see this documentation.
Yes, the SDK supports building Vulkan applications without a driver or hardware. The SDK installs the Vulkan header files and the Vulkan loader library in standard system locations.
A Vulkan application compiles using the Vulkan header files. It links using the Vulkan loader library. No Vulkan-capable hardware or drivers are needed for compilation and linking.
If you mix the use of Vulkan and OpenGL within an application, the debug and validation tools in the LunarG SDK give you information for the Vulkan API only.
The LunarG SDK is tested against the two latest Ubuntu LTS releases and various other Linux distributions. For the specific distributions refer to the LunarG SDK documentation found on LunarXchange (https://vulkan.lunarg.com/).
LunarG is an independent software company sponsored by Valve to help build out the ecosystem for the Vulkan API. In that capacity, LunarG is a member of the Khronos Vulkan Working Group.
The LunarG SDK is tested against the two latest Ubuntu LTS releases and various other Linux distributions. For the specific distributions refer to the LunarG SDK documentation found on LunarXchange (https://vulkan.lunarg.com/). The SDK installer does not install files to system locations that require administrator privileges. The LunarG Vulkan SDK for Linux is a self-extracting installer. The installer will create a local SDK directory of the form VulkanSDK/<version> in the current working directory. See the Getting Started guide for Linux found on LunarXchange (https://vulkan.lunarg.com/) for more details.
The LunarG SDK provides the critical and canonical Vulkan API Loader and Validation Layers. In addition, it provides sample code as examples, and other tools such as RenderDoc, vktrace/vkreplay.
If you are developing a Vulkan application and are having issues and you are not sure if the issues are in the Vulkan loader, or Vulkan validation layers, or other components within the SDK, you can submit it to LunarXchange.
The engineers at LunarG will help triage the issue and determine if it is a loader or validation layer issue and work with the corresponding public GitHub project as needed to get it resolved.
LunarXchange also allows you to create a private organization. This is useful when a company needs help from LunarG on an SDK component but does not want the issue to be public. The private organization allows for confidential sharing of information between LunarG and the organization. If you are interested in having a private organization on LunarXchange, contact firstname.lastname@example.org.
The original proposal for Vulkan was basically a cleaned up version of Mantle. AMD got the conversation going, but over an 18-month period there were contributions from many other Khoronos members. Some are small tweaks and others are major features. For example, render pass was never in Mantle, yet it’s a core part of Vulkan now.
Some of the API names are the same, but it is a significant update. There are some very important differences and enhancements, and Vulkan is cross-vendor, cross-platform, so we’ve landed in a really good place. Overall Vulkan is truly a better API.
The professional design community is interested in Vulkan. It is not designed just for games; any application that is CPU bound can benefit from Vulkan.
For example, Vulkan can help with a CPU-bound, high-end CAD application model with hundreds of millions of polygons. In the professional authoring industry, there’s a lot more legacy code and OpenGL is not going away. But if CAD application developers want to migrate to Vulkan to take advantage of things like the multi-threading for large model interactivity, that is the kind of application that Vulkan is designed to enable.
Microsoft has not expressed intent to support Vulkan. However, there are well defined mechanisms by which IHVs can ship a Vulkan driver on any version of Windows. But it will be as it is the case now with OpenGL. That is, it is up to the application to negotiate with the implementation to install an appropriate Vulkan driver for the hardware that is on the machine.
Vendors are enabled to ship drivers for whichever API they wish, and Vulkan drivers are already shipping from multiple hardware vendors for multiple versions of Windows.
Vulkan is available on all versions of Windows that are on DirectX 12, so there is potentially some value to the developer community to having a single API that spans multiple Windows versions.
There’s no direct support for SLI or alternate frame rendering in the Vulkan API that we’re aware of. Multi-GPU support of many kinds is a very high priority.
Apple is a member of Khronos and active in several of Khronos APIs, but the company has not publicly stated support for Vulkan. From Khronos’ point of view, there is no barrier to any OS platform adopting Vulkan.
You can find out all the official details about conformance testing on the Khronos website: https://www.khronos.org/conformance
If you have multiple queues, it might make sense to submit work to each queue from different threads. Serialize on a single queue, then have multiple threads submitting to a single queue if it’s convenient in your app.
If you just have multiple threads to submit, synchronization is a problem. There’s probably no real benefit to doing that.
It’s a design intent of Vulkan that submit is supposed to be very cheap. The heavy lifting is done at command buffer construction time, so the expected model for a given render target is to multi-thread the command buffer construction like crazy, but then if you marshal all of those and have a single thread submit them, that’s not going to hurt you. It’s not going to be the top pull.
Also, If an application remains single threaded, you can still expect CPU performance improvements and the stuttering improvements and so on that Vulkan offers. Multi-thread it is not a requirement to reap the benefits of Vulkan.
There are excellent debugging capabilities provided by tools such as the LunarG SDK, and we look forward to other products from the community. In particular, RenderDoc (included in the LunarG SDK) is the best tool currently available for it.
If you use them wisely, there are certainly things there that desktop GPUs can take advantage of. It’s not a mobile-only feature.
On Linux, the loader detects the drivers via a JSON file that’s installed in some system communications. The JSON file indicates where the actual driver library is. There are also some environment variable overrides that you can use to point to a different location rather than a system location.
For more detailed information review the SDK Linux documentation at LunarXchange (vulkan.lunarg.com)
The core Vulkan specification has no platform dependencies whatsoever. We have brought Windows system integration closer to the core in the sense that Windows system integration is now a core extension rather than a separate API. The WSI, for instance, on Windows vs. Linux is mostly the same extension. There would be some difference there, but a lot would be the same calls.
The Vulkan header file defines multi-sampling modes. Multi-sampling is the basic mode. Super sampling is not formally supported, but per-sample shading which is similar is supported. The Vulkan specification allows implementors to expose multi sampling and super sampling directly. We require every implementation to support 4x multi sampling.
The Khronos working group is very interested in your input. If you see an extension that is of intense interest for addition to the core, notify them on the Khronos Github platform.
There is no multiple GPU support in version 1.0. That was unfortunately a feature Khronos had to cut in order to preserve schedule. It is expected to be near the top of the list for Vulkan 1.1. It is perfectly possible for a Vulkan implementation to expose multiple GPUs. What Vulkan currently can’t do is allow resource sharing between them. So from a point of view of, for example, a Windows system manager, its possible to recognize multiple ways to render to a surface and then use operating system hooks to transfer that to the screen. What Vulkan doesn’t have is the ability to share a texture or a render target between multiple GPUs.
Vulkan is a very low-level API. If your GPU is capable of it, you can draw with it. At the moment it exposes pretty much the set of primitives that core OpenGL does, so if you’re talking about drawing lines and screen-line, co-ads, and things like that, sure. If IHVs have support for real, actual hardware that accelerates 2D better than you could do it with a 3D engine, then they will probably become available as extensions.
Vulkan is unique among modern APIs in terms of treating mobile and desktop equally. It is possible to write paths in a Vulkan application which will suffer no penalty on a desktop architecture but will equally exploit all the capabilities which are offered by a mobile architecture. This is primarily through the render paths and the command buffer structure of the API.
Interface problems exist between the OpenGL family APIs and platform APIs due to external delegation of Windows System Integration (WSI). Vulkan brings these things to the surface so the Vulkan loader is visible, explicit, and endorsed by the entire working group.
Solving platform integration is part Vulkan, as opposed to OpenGL which says it’s someone else’s problem. The intent is to present the best solution based on variations of what’s been done with OpenGL. If needed, there are projects on Khronos Github that you can post related issues to.
Yes, and that’s important because that’s one of the innovation factors. It allows you to experiment at your own pace.
Vulkan was based on an AMD graphics API called Mantle (named after the layer in the Earth’s crust). The logo of Mantle is an erupting volcano. Vulkan is named after the Roman god of the same name who was thought to be responsible for volcanos.
This was in part due to the fact that Vulkan is a different API and has no backwards compatibility with existing GL applications, which the name GLnext/nextGL may imply.
The LunarG Vulkan SDK includes samples from the lunarg-github/samples GitHub repository. You can submit samples there.
A WebVulkan won’t be needed. If you are creating a web application in 3D, use WebGL, especially since Apple will not be supporting Vulkan in the foreseeable future. It’s native in the browsers and you don’t need a plug in. As WebGL evolves, it’s going to very carefully depict the functionality that could be supported on every platform.
The LunarG® Vulkan™ SDK provides you with a variety of resources to aid in creating Vulkan applications.
The SDK includes:
- Vulkan loader
- Validation layers
- Trace and replay tools
- SPIR-V™ tools
- Vulkan Runtime Installer
- Documentation, samples, and demos
The LunarG Vulkan SDK is available on the LunarXchange (vulkan.lunarg.com) portal.
The SDK offers a number of advantages:
- Vulkan, by design, is a very low-level API that provides applications direct control over GPU acceleration with minimized CPU overhead and efficient multi-threaded performance. The SDK provides tools to help you develop to this lower level API.
- The SDK is available for Linux and Windows® operating systems. Because Vulkan is a direct competitor of Microsoft® DirectX12®, Microsoft will not offer Vulkan developer tools for Windows. The SDK provides comprehensive tools for both Linux and Windows operating systems.
- Vulkan is a cross-platform API that supports a range of devices including desktop, mobile, and console. The Vulkan loader and validation layers are canonical pieces that are critical in achieving this cross-platform compatibility. These components are open source, and you can choose to build them. To speed development efforts, the SDK includes the loader and layers already built for you.
- Because Vulkan is a very low-level API, a simple program is much longer to write compared to OpenGL. The included utilities and samples help you learn the process.
Vulkan requires drivers to omit most traditional error checks; drivers assume that the application is using the driver correctly.
The validation layers are the key for identifying errors in using the API during development. The layers check for correct implementation of the Vulkan API and return any errors found.
You can enable validation layers during application development, and then disable them for production shipments.
Yes, examples demonstrating the use of the Vulkan API, with utilities that you can leverage and use, are located in the SDK.
You can capture a trace file of the Vulkan API calls and replay them using the trace tools. Commonly, application developers share application workloads with third parties, such as IHVs (Independent Hardware Vendors), who don’t have access to their application.
- The trace tool (vktrace) captures the Vulkan API activity in an application and stores it in a file.
- The replay tool (vkreplay) plays back the trace file, independent of the application.
As an example, this capability is useful for reporting a rendering problem to an IHV. The trace file reduces the need for the IHV to set up an environment to reproduce the problem.
Loader: Consistent loader behavior across platforms is key to Vulkan. The Khronos-branded loader binary and installation package is included in the LunarG Vulkan SDK. The loader discovers and manages the Vulkan devices/drivers and layers available to the application.
Loader installer package: The SDK also includes an installation package for the loader binary, for those who want to use the installation package directly for installing a Vulkan loader on a system.
The LunarG Vulkan SDK is supported on 64-bit Windows systems:
- 64-bit Microsoft Windows 7, 8, 8.1, and 10
The LunarG Vulkan SDK is supported on 64-bit Linux systems:
- 14.04 LTS
- 16.04 LTS
- Other Debian derivatives may work but are unverified
The Vulkan shader language is SPIR-V, which is a low-level binary intermediate representation (IR). The Vulkan API requires the SPIR-V format for all shaders.
SPIR-V splits the compiler chain, enabling high-level language front ends to emit programs in a standardized intermediate form to be ingested by Vulkan.
Eliminating the need for a built-in high-level language source compiler significantly reduces GPU driver complexity, enabling a diversity of language front ends.
No. You can use existing GLSL shaders with the LunarG SDK included tool glslangValidator, which creates SPIR-V shaders from equivalent GLSL shaders.
Shader Creation Tool
The glslangValidator creates SPIR-V shaders from equivalent GLSL shaders.
SPIR-V Disassembler and Assembler Tools
Disassembler spirv-dis converts SPIR-V shader into human-readable and parsable form to help with debugging. Assembler spirv-as takes edited, disassembled output and assembles it.
SPIR-V Remapper Tool
The spirv-remap tool enhances compression of SPIR-V binary files via entropy reduction, including optional stripping of debug information and dead functions. As an example, the tool is useful when games have large numbers of shaders and need smaller file sizes.
RenderDoc is a graphics debugging tool that’s included in the LunarG Vulkan SDK. It allows you to capture a single frame of an application, then load that capture up in an analysis tool to inspect the API use and GPU work in detail. For more information, see the RenderDoc GitHub page.
Documentation for the LunarG SDK is available on LunarXchange. It includes:
- Getting Started Guides
- Vulkan Tools Framework
- Vulkan Loader Specification and Architecture
- Vulkan Validation Layers and Debugging Layers
- Trace and Replay Tools
- SPIR-V Toolchain
- Vulkan Samples
- Vulkan Specification
- Vulkan Man Pages
- Various Vulkan Extensions
LunarG provides ongoing maintenance for the loader and validation layers and ongoing development to produce samples and other tools and layers.
For SDK-related support from LunarG, submit issues on the LunarXchange portal.
Display drivers should be obtained by visiting the appropriate hardware vendor’s website.