Vulkan developers: Are you generating SPIR-V shaders from HLSL using glslangValidator built from https://github.com/KhronosGroup/glslang? In order to guarantee that your SPIR-V is legal for Vulkan, you must now include spirv-tools when building glslang. This can be done by running update_glslang_sources.py located in the glslang home directory before the configuration cmake step. This clones the latest “known-good” version of spirv-tools into the glslang/External directory. If spirv-tools is not included in glslang, a warning is printed during the configuration cmake call stating that illegal SPIR-V may be generated for HLSL shaders. Starting with the next LunarG Vulkan SDK release, the glslangValidator executable included in the SDK will be built with spirv-tools included. The SPIR-V is made legal by using spirv-opt, the optimizer from spirv-tools. The HLSL shading language requires certain optimizations to allow for generation of SPIR-V that is legal for Vulkan. The optimizer in glslang can be disabled with the -Od option, although the resulting SPIR-V may not be legal for Vulkan if generated from HLSL. Note that the optimizer in glslang is not invoked for GLSL shaders by default. If you wish to optimize SPIR-V for size, glslang now offers the -Os option. This can be invoked when compiling from both HLSL and GLSL shaders. This option is only available if spirv-tools was included during the glslang build. Complete instructions for building glslang can be found in the README.md file in the glslang home directory.

Learning the Vulkan API? Check out this overview of Vulkan Loader and Layers. Vulkan is a layered architecture, made up of the following elements: 1) The Vulkan Application, 2) The Vulkan Loader, 3) Vulkan Layers, and 4) Installable Client Drivers (ICDs). >While this tutorial is primarily targeted at developers of Vulkan applications, drivers, and layers, the information contained in it could be useful to anyone wanting a better understanding of the Vulkan runtime.  These general concepts are applicable to the loaders available for Windows-, Linux-, and Android-based systems. The Loader The application sits on one end of, and interfaces directly with, the loader. On the other end of the loader from the application are the ICDs, which control the Vulkan-capable hardware. An important point to remember is that Vulkan-capable hardware can be graphics-based, compute-based, or both. Between the application and the ICDs the loader can inject a number of optional layers that provide special functionality. The loader is responsible for working with the various layers as well as supporting multiple GPUs and their drivers. Any Vulkan function may wind up calling into a diverse set of modules: loader, layers, and ICDs. The loader is critical to managing the proper dispatching of Vulkan functions to the appropriate set of layers and ICDs. The Vulkan object model allows the loader to insert layers into a call chain so that the layers can process Vulkan functions prior to the ICD being called. This tutorial is intended to provide an overview of the necessary interfaces between each of these. Goals of the Loader The loader was designed with the following goals in mind. Support one or more Vulkan-capable ICDs on a user’s computer system without interference between them. Support Vulkan Layers, which are optional modules that can be enabled by an application, developer, or standard system settings. Minimize overall performance impact to a Vulkan application. Layers Layers are optional components that augment the Vulkan system. They can intercept, evaluate, and modify existing Vulkan functions on their way from the application down to the hardware. Layers are implemented as libraries that can be enabled in different ways (including by application request) and are loaded during CreateInstance. Each layer can choose to hook (intercept) any Vulkan functions which in turn can be ignored or augmented. A layer does not need to intercept all Vulkan functions. It may choose to intercept all known functions, or, it may choose to intercept only one function. Some examples of features that layers may expose include: Validating API usage Adding the ability to perform Vulkan API tracing and debugging Overlaying additional content on the application’s surfaces Because layers are optional, you may choose to enable layers for debugging your application, but then disable any layer usage when you release your product. Read more information about the Vulkan loader and layers [here].