LunarG updated the vulkaninfo program to improve the user experience. This program is located in the Vulkan SDK available on the LunarXchange website. Two changes were made to vulkaninfo — the addition of the 1) –-html and 2) -j and –-json options.
LunarG’s VLF simplifies Vulkan validation layer creation
Vulkan Layer Factory simplifies Vulkan validation layer creation. LunarG creates tools to help simplify Vulkan development. The LunarG Vulkan Layer Factory (VLF), our latest offering, is a framework based on the canonical Vulkan layer model that facilitates the creation of Vulkan Layers.
Extend your Vulkan test coverage with free LunarG Device Simulation tool
Do you have a test lab with examples of all the GPUs you hope your application will support? Is your Vulkan application stress-tested to ensure it behaves correctly across the wide range of hardware available in the marketplace? If either answer is “no,” LunarG offers a free tool that could extend your test coverage and increase your peace of mind. LunarG Device Simulation Tool Overview The LunarG Device Simulation layer helps test across a wide range of hardware capabilities without requiring a physical copy of every device. It can be applied without modifying any application binaries, and in a fully-automated fashion. The Device Simulation layer (aka DevSim) is a Vulkan layer that can override the values returned by your application’s queries of the GPU. DevSim uses a JSON text configuration file to make your application see a different driver/GPU than is actually in your system. This capability is useful to verify that your application both a) properly queries the limits from Vulkan, and b) obeys those limits. LunarG announced DevSim at SIGGRAPH in the summer of 2017, and the layer library is available pre-built in the LunarG Vulkan SDK. Since that announcement, DevSim has continued to evolve, and now supports even more features. The DevSim layer works for all Vulkan platforms (Linux, Windows, and Android). It is open-source software on GitHub, and the code strives to be clear and well-documented to serve as an example for writing Vulkan layers. The role of DevSim is to “simulate” a less-capable Vulkan implementation by constraining the features and resources of a more-capable implementation. Note that the actual device in your machine should be more capable than that which you are simulating. DevSim does not add capabilities to your existing Vulkan implementation by “emulating” additional capabilities with software; e.g. DevSim cannot add geometry shader capability to an actual device that doesn’t already provide it. Also, DevSim does not “enforce” the features being simulated. For enforcement, you would continue to use the Validation Layers as usual, in conjunction with DevSim. Using DevSim DevSim supports a flexible configuration file format using JSON syntax. The configuration file format is defined by a formal JSON schema available on the Khronos website, so any configuration file may be verified to be correct using freely-available JSON validators. Browsing through the schema file, you can see the extent of parameters that are available for your configuration. As a convenience, DevSim supports loading multiple JSON files, so your configuration data can be split among separate files for modularity as desired. How DevSim Works DevSim builds its internal data tables by querying the capabilities of the underlying actual device, then applying each of the configuration files “on top of” those tables. Therefore you only need to specify the features you wish to modify from the actual device; tweaking a single feature is easy. Here’s an example of a valid configuration file for changing only the maximum permitted viewport size: { “$schema”: “https://schema.khronos.org/vulkan/devsim_1_0_0.json#”, “VkPhysicalDeviceProperties”: { “limits”: { “maxViewportDimensions”: [1024, 1024] } } } Simulating Entire Real-World Devices If you instead wish to simulate entire real-world devices, LunarG has collaborated with the Vulkan Hardware Database to make their data compatible with the DevSim schema. You can download device configurations from the website in JSON format, and use those configuration files directly with DevSim. Reporting Issues Should you have any issues or suggestions for the Device Simulation layer, please create an issue at the LunarG VulkanTools GitHub repository, with “DevSim” in the title. Additional Information Check out the links below: Khronos BOF from SIGGRAPH 2017 pp 81-83 DevSim documentation DevSim source code in LunarG VulkanTools repository on GitHub DevSim JSON schema Vulkan Hardware Database Learn More about LunarG LunarG’s software engineering experts create innovative products and services using leading-edge 3D graphics and shader compiler technologies. Click here to learn how we can help you.
A Simpler Way to Reduce Vulkan SPIR-V Size with New spirv-opt -Os
LunarG is pleased to announce the release of a new option in spirv-opt, which was designed to reduce SPIR-V size. This new option, -Os, allows developers to reduce SPIR-V size without specifying individual passes of spirv-opt.
Valve + LunarG Launch Graphics Testing Service for Mesa Developers
LunarG has been hard at work developing the LunarG Mesa Graphics Testing Service. Today we’re happy to announce with Valve that we’re making the service available to the Mesa development community.
Help for Building and Debugging Vulkan Apps and Games
LunarG provides a Vulkan API SDK, which offers a tools framework for building and debugging applications and games. The main components in the Vulkan tools framework include the Vulkan API, a Common Loader, Validation and Debugging Layers, Trace and Replay Tools, and SPIR-V-Related Tools.
Use SPIR-V tools for Vulkan compliant shaders
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.
Overview of Vulkan Loader and Layers
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].
