Announcements, articles, and blurbs from Khronos and Khronos members about Khronos tech, conformant products, and more. If you are a interested in submitting a blog post, please check out our Blog Guidlines.
OpenXR is the Khronos Group’s royalty-free, open standard for high-performance access to Augmented Reality (AR) and Virtual Reality (VR)—collectively known as XR—platforms and devices. In a significant step in OpenXR’s rollout across the industry, the Working Group has released its Conformance Test Suite, published the tests as Apache 2.0-licensed open source software on GitHub, and launched the OpenXR 1.0 Adopters Program so that implementations can be officially conformant for the first time.
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.
A big part of why we built glTF™ is to make it easy to serve 3D models to websites across the Internet. What better way to demonstrate this than to hook in to other web standards? I work on the Chrome XR team and we are proud to announce the addition of support for Augmented Reality (AR) to the WebXR API in Chrome 81, which has now rolled out to the world.
However, using WebXR still requires using WebGL™, which is a low-level API. The o
With an increasing number of OpenCL run-times supporting ingestion of SPIR-V, OpenCL developers may wish to use offline compilation to precompile SPIR-V kernels that can be used portably across multiple OpenCL implementations. Consistently using the same front-end compiler can enhance cross-vendor deployment consistency, while reducing overall compile times and eliminating the need to ship OpenCL C source code. Kernel development may also be more
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.
My name is Michael Wong, and in this blog I will talk about SYCL™, the Khronos® Group’s open standard for programming heterogeneous processors in “single-source” standard C++ and the SYCL working group’s activities. I have had the pleasure of chairing SYCL for the last four years, taking over from Codeplay’s Andrew Richards, shepherding a group of insanely talented people from many companies who are driving forward the technology of heterogeneous, modern C++. In this blog, I’ll tell you about my experience at SC19 with SYCL and Intel’s oneAPI that implements the SYCL standard. In future blogs, I would like to tell you more about SYCL features and future directions.
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
Education has evolved to include 3D content delivered directly to a students mobile devices, allowing them to navigate around the artifact at their own pace.
In the last several weeks learning has moved from the classroom into the home, as schools across the world have temporarily closed.
The old way of learning involved reading textbooks or consuming content delivered through paper handouts. Sometimes live specimens or scale models could be us
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.
The Khronos Group gives out special recognition awards called Khronies. Khronies are handed out at our Face-To-Face meetings for outstanding contributions to Open Standards. At our last face to face in Barcelona, four Khronie Awards were given out.
OLV builds tools and content that help visualize things before they can be touched. Our array of tools help Microsoft Retail to collaborate on the London flagship store from across the globe, a baseball player to customize his own Official Helmet and Glove of Major League Baseball®, and a varsity volleyball team to design their next uniform from Mizuno.
glTF™ is a Khronos royalty-free specification for the efficient transmission and run-time loading of 3D scenes and models by engines, browsers and applications. glTF minimizes both the size of 3D assets and the runtime processing needed to unpack and use them. glTF has become widely adopted throughout the industry, becoming the equivalent of a ‘JPEG for 3D’. glTF is used by hundreds of content tools and services, streamlining 3D authoring w
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.