In the world of simulation we are accustomed to dealing with both extremely large datasets and very long compute times. Even with modern GPU acceleration and large amounts of memory the resolution of the domain required to accurately simulate even a subset of real-world physics can result in compute times that run into the days or even weeks and datasets that are many tens of gigabytes in size. When you have datasets this large it can be difficult to distill this down into something that you can derive valuable insights from and keeping these enormous datasets in the cloud allows us to use scalable cloud resources to process the data. This is something that has become more of a pressing issue as the simulation capabilities of Autodesk Fusion 360 have expanded.
In early 2018 the Vulkan Working Group at Khronos started to explore how to seamlessly integrate hardware accelerated video compression and decompression into the Vulkan API. Today, Khronos is releasing a set of Provisional Vulkan Video acceleration extensions : ‘Vulkan Video’. This blog will give you an overview of Vulkan’s new video processing capabilities and we welcome feedback before the extensions are finalized so that the
Synchronization is a critical but often misunderstood part of the Vulkan API. The new VK_KHR_synchronization2 extension includes several improvements to make Vulkan Synchronization easier to use, without major changes to the fundamental concepts described below. We’ll highlight key differences introduced with Synchronization2 throughout the blog.
The newly released VK_KHR_synchronization2 extension brings extensive improvements to Vulkan queue submission, events, and pipeline barriers resulting in API significant usability enhancements for developers.
Synchronization2 highlights include:
Data for semaphores and command buffers is passed in arrays of structures, rather than in separate arrays spread across multiple structures, to streamline queue submissions.
Barrier pipeline stage masks
Today, the functionality of the Vulkan SDK gets a major upgrade for Vulkan developers targeting Apple platforms. LunarG is now shipping Device Simulation (DevSim) and Validation layers for the Vulkan SDK on macOS in addition to Linux and Windows. DevSim layers enable Vulkan application development on a highly-capable development system by "simulating" a less-capable target Vulkan implementation through constraining the reported features and resources on the more-capable platform. Validation layers verify that applications are correctly using the reported Vulkan functionality. The validation layers and associated Vulkan loader on macOS also now support Apple Silicon via Universal Binaries.
For the past two years, Holochip has been working on light field technology for the US Navy’s Aegis program. The program calls for a table top light field display that can accommodate horizontal and vertical real-time parallax. In October 2020, the team working on OpenXR™ at Holochip released an open source Vulkan® example project and started work with light field display technology using the OpenXR API. As a result of both efforts, Holochip has discovered a method of light field real-time rendering that is built upon the Khronos Group’s Vulkan Ray Tracing extensions.
The Khronos Vulkan Ray Tracing Task Sub Group (TSG) has developed and released a set of extensions that seamlessly integrate ray tracing functionality into the existing Vulkan framework. This blog summarizes how the Vulkan Ray Tracing extensions were developed, and illustrates how they can be used by developers to bring ray tracing functionality to their applications.
Today, the Khronos Vulkan Working Group has released the final Vulkan Ray Tracing extensions that seamlessly integrate ray tracing functionality alongside Vulkan’s rasterization framework, making Vulkan the industry’s first open, cross-vendor, cross-platform standard for ray tracing acceleration. The final ray tracing functionality is defined by a set of 5 extensions, namely VK_KHR_acceleration_structure, VK_KHR_ray_tracing_pipeline, VK_KHR_ray_query, VK_KHR_pipeline_library, and VK_KHR_deferred_host_operations. ISVs played a pivotal role in shaping the extension to enable hybrid rendering—where rasterization and ray tracing are used in tandem to achieve compelling levels of visual fidelity and interactivity.
Today, Khronos has released the final versions of the set of Vulkan, GLSL and SPIR-V extension specifications that seamlessly integrate ray tracing into the existing Vulkan framework. This is a significant milestone as it is the industry’s first open, cross-vendor, cross-platform standard for ray tracing acceleration - and can be deployed either using existing GPU compute or dedicated ray tracing cores. Vulkan Ray Tracing will be familiar to anyone who has used DirectX Raytracing (DXR) in DirectX 12, but also introduces advanced functionality such as the ability to load balance ray tracing setup operations onto the host CPU. Although ray tracing will be first deployed on desktop systems, these Vulkan extensions have been designed to enable and encourage ray tracing to also be deployed on mobile.
The Vulkan Working Group has just released the VK_KHR_fragment_shading_rate extension, which provides a new, flexible technique to control the fragment shading rate, enabling developers to perform shading at a lower resolution than the render targets. This fine level of control allows developers to focus shading resources where they are needed, which ultimately increases rendering performance and quality.
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.