Over the last few years, providing the functionality of one graphics API by layering over another API has become increasingly popular. This post explores the value of layered implementations to the graphics community and provides details on a significant announcement from Khronos’ ongoing Vulkan® Portability™ initiative—the release of the provisional version of the Vulkan Portability extension with multiple shipping implemen
Correct synchronization is needed to ensure correct results from Vulkan operations (whether graphical or computational). Modern graphics hardware is both parallel and pipelined, with various operations happening simultaneously for performance reasons. Vulkan has a limited number of ordering guarantees but, for most operations, it is the application's responsibility to inform the implementation when ordering is required between operations. The ne
Adaptive Scalable Texture Compression (ASTC) is an advanced lossy texture compression format, developed by Arm and AMD and released as royalty-free open standard by the Khronos Group. It supports a wide range of 2D and 3D color formats with a flexible choice of bitrates, enabling content creators to compress almost any texture asset, using a level of compression appropriate to their quality and performance requirements.
ASTC is increasingly becom
Arm has released a new comprehensive ASTC Guide to help developers who wish to use ASTC technology to compress textures for 3D games and applications. The new guide contains a detailed ASTC algorithm overview, explains ASTC benefits, provides developers advice for achieving best compression results, and contains information on popular encoding tools -- as well as usage with game engines.
ASTC (Adaptable Scalable Texture Compression) is an exceptionally efficient compression technology, which allows encoding of a wide variety of texture formats at bit-rates of 8 bits per pixel to below 1 bit per pixel. ASTC was contributed by Arm, developed under the cooperative process at Khronos® and is royalty-free when used with Khronos’ OpenGL® ES and Vulkan® APIs. ASTC enables the size of textures used in 3D games and applications to be significantly reduced while being downloaded and stored – saving memory size, access bandwidth and reducing overall application size while retaining high image quality. These benefits are especially valuable on mobile platforms leading to ASTC becoming the most widely used texture compression format for Vulkan and OpenGL ES applications on Android.
We often hear that developers would like a single location to find all the available resources for learning Vulkan and wanted to create a list of the most up to date and valuable set of resources. We’ve made good progress on new resources, releasing the Vulkan Code Samples and Vulkan Guide both of which we encourage developers of all skill levels to check out.
However, there is always more that we can do to improve that state of available
Today the Khronos Vulkan Ray Tracing Task Sub Group (TSG) is announcing the public release of the provisional Vulkan Ray Tracing extensions. The Ray Tracing TSG was formed in early 2018 and tasked to bring a tightly integrated, cross-vendor, ray tracing solution to Vulkan, this release marks the culmination of the first phase of the TSG’s mandate.
HLSL support in Vulkan has come a long way since its introduction. Over the past couple of years HLSL in Vulkan has made amazing strides to hit a critical maturation point and earned the coveted label of production ready. HLSL in Vulkan has been achieved through integrating a SPIR-V backend into DXC, Microsoft’s open source HLSL compiler (the encircled section in Figure 1 below), and Khronos’ glslang. It has been no small effort to bring it to the level of quality we enjoy today. Coordinated efforts and contributions of all sizes from IHVs, ISVs, independent developers, and of course Khronos came together to make it all happen.
The original Vulkan synchronization APIs relied on two separate coarse-grained primitives: VkSemaphore and VkFence. Both of these were reusable binary-state objects with slightly different purposes and behavior. VkSemaphore allowed applications to synchronize operations across device queues. VkFence facilitated device to host synchronization. Together, they enabled applications to observe and control the execution of command buffers and other queue commands, but they inherited various limitations of the underlying OS and device mechanisms at the time which made them somewhat difficult to use.
The Vulkan Working Group has just released the VK_KHR_performance_query extension, which provides a cross-vendor common mechanism to expose performance metrics. These may be used to obtain data from a Vulkan device, typically a graphics card or SoC, to measure the workload demand and assess the impact of application modifications and optimizations.
Today, The Khronos® Group releases the Vulkan® Unified Samples Repository, a new central location where anyone can access Khronos-reviewed, high-quality Vulkan code samples in order to make development easier and more streamlined for all abilities. Khronos and its members, in collaboration with external contributors, created the Vulkan Unified Samples Project in response to user demand for more accessible resources and best practices for developing with Vulkan.
The recently formed Khronos OpenCL Tooling Subgroup has been focused on developing and enhancing open source tools and components, targeted at embedded systems and heterogeneous computation applications; the new tools and resources are available to the entire OpenCL ecosystem.
Vulkan is an extremely powerful new-generation graphics and compute API that affords developers considerable flexibility—but many developers are realizing that what works best for desktops may not deliver optimal results on mobile. That’s why Arm Technology has put together the best practices for Vulkan developers on mobile.
The Vulkan/SPIR-V memory model was built on the foundation of the C++ memory model, but ended up diverging in a number of places.
A lot of how GPU programming models work across modern graphics APIs has evolved through years of development, reflecting the markets that those APIs have targeted. Naturally, the Vulkan/SPIR-V memory model has made several decisions that reflect this. We added several new facets to the model, including scopes, storage classes, and memory availability and visibility operations to name some of the more prominent ones.
However, It is not a strict superset either, and there are a few places where some features have been omitted for similar reasons. For example, sequential consistency is not supported, and forward progress guarantees are limited.
This post aims to give a high-level overview of the differences, explaining what the differences are, why they are different, and how (if at all) C++ concepts can map to the Vulkan/SPIR-V memory model. It is aimed primarily at people already familiar with the C++ memory model who either want to get some insight into what the differences are or those who are curious about why we took the direction we did.
Khronos has released a provisional Vulkan Memory Model Specification that includes extensions for Vulkan, SPIR-V, and GLSL and gives Vulkan developers additional control over how their shaders synchronize access to should cooperate safely over memory operations in a parallel execution environment. In tandem with the extension specification, Khronos has released memory model extension conformance tests to enable implementers to do early tests on their shader compilers to ensure that the specified memory synchronization is implemented correctly. The memory model will have an Alloy description of the extension functionality to enable formal modeling and experimentation.