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.
Virtual reality and augmented reality have great potential for entertainment, training and education, and other industries, but are currently being held back by industry fragmentation. The Khronos Group is addressing this by creating the OpenXR API, and shares details of its creation and considerations, as well as the first demo of the API at SIGGRAPH 2018.
Subgroups are an important new feature in Vulkan 1.1 because they enable highly-efficient sharing and manipulation of data between multiple tasks running in parallel on a GPU. In this tutorial, we will cover how to use the new subgroup functionality.
Bringing 25 graphics standards to various industries is a collaborative effort, run worldwide across Khronos’ over 100 member companies. We come together three times each year for face-to-face meetings, which present the rare opportunity for all of our active members, Working Groups, and personnel to discuss the goals for the upcoming year to drive our standards forward. These events also present the opportunity to give Khronie Awards to those whose contributions made significant impact to Khronos, our standards, and our mission.
Recently I asked the community for beginner-friendly resources on Vulkan, and I compiled a list of them that you can find below. For the beginners reading this, Vulkan is a new graphics API-- in other words, a way to communicate with your GPU and make it do things. It's managed by the Khronos Group, which means it's under multi-company governance - being managed by the industry for the industry. Anyone who wants to do work on GPUs (not restricted to graphics programmers!) should at least have a high level knowledge of what it is.