The Khronos Group Releases OpenXR 0.90 (Provisional)

Subject: General Tech | March 19, 2019 - 01:20 AM |
Tagged: Khronos, openxr

At the Games Developers Conference in San Francisco, the Khronos Group has published the first, provisional release of the augmented reality and virtual reality API: OpenXR 0.90. The goal is to allow the general public to implement it into their software so they can provide feedback (via the official forums) before it launches into 1.0.


The last time we’ve mentioned OpenXR was SIGGRAPH back in August. That event had a demo area on the show floor with the Epic Showdown VR demo, which evolved into Robo Recall. On that end, Epic plans to continue support for OpenXR, and they pride themselves as the engine that powers the original demo. Unity has also responded positively to OpenXR, but their quoted statement doesn’t make any specific promises. Microsoft and Collabora are each, separately, providing hardware implementations of the new API. Oculus plans to support the API when it reaches 1.0 status. HTC also wants to support OpenXR with the Vive, although Valve is nowhere to be seen on the list of quotes. Google is also nowhere to be seen on the list.

You can check out the press release on the Khronos Group website.

EWC 2019: Vulkan Safety Critical (SC) Working Group Created

Subject: Graphics Cards | February 26, 2019 - 12:41 AM |
Tagged: Khronos, Khronos Group, vulkan, vulkan sc, opengl, opengl sc

The Khronos Group, the industry body that maintains OpenGL, OpenCL, EGL, glTF, Vulkan, OpenXR, and several other standards, has announced the Vulkan Safety Critical (SC) Working Group at Embedded World Conference 2019. The goal is to create an API that leverages Vulkan’s graphics and compute capabilities in a way that implementations can be safe and secure enough for the strictest of industries, such as automotive, air, medical, and energy.


It's a safety hammer, I promise. (No I don't.)

The primary goal is graphics and compute, although the working group will also consider exposing other hardware capabilities, such as video encode and decode. These industries currently have access to graphics through OpenGL SC, although the latest release is still significantly behind what a GPU can do. To put it into perspective – the latest OpenGL SC 2.0 (which was released in 2016) has less functionality than the original release of WebGL back in 2011.

While OpenGL SC 2.0 allows programmable vertex and fragment (pixel) shaders, it falls short in many areas. Most importantly, OpenGL SC 2.0 does not allow compute shaders; Vulkan SC is aiming to promote the GPU into a coprocessor for each of these important industries.

There is not much else to report on at this point – the working group has been formed. A bunch of industry members have voiced their excitement about the new API’s potential, such as Codeplay, Arm, and NVIDIA. The obvious example application would be self-driving cars, although I’m personally interested in the medical industry. Is there any sort of instrument that could do significantly more if it had access to a parallel compute device?

If you are in a safety-critical enterprise, then look into joining the Khronos Group.

Intro and NNEF 1.0 Finalization

SIGGRAPH 2018 is a huge computer graphics expo that occurs in a seemingly random host city around North America. (Asia has a sister event, called SIGGRAPH Asia, which likewise shuffles around.) In the last twenty years, the North American SIGGRAPH seems to like Los Angeles, which hosted the event nine times over that period, but Vancouver won out this year. As you would expect, the maintainers of OpenGL and Vulkan are there, and they have a lot to talk about.

In summary:

  • NNEF 1.0 has been finalized and released!
  • The first public demo of OpenXR is available and on the show floor.
  • glTF Texture Transmission Extension is being discussed.
  • OpenCL Ecosystem Roadmap is being discussed.
  • Khronos Educators Program has launched.

I will go through each of these points. Feel free to skip around between the sections that interest you!

Read on to see NNEF or see page 2 for the rest!

Subject: General Tech
Manufacturer: The Khronos Group

Don't Call It SPIR of the Moment

Vulkan 1.0 released a little over two years ago. The announcement, with conformant drivers, conformance tests, tools, and patch for The Talos Principle, made a successful launch for the Khronos Group. Of course, games weren’t magically three times faster or anything like that, but it got the API out there; it also redrew the line between game and graphics driver.

The Khronos Group repeats this “hard launch” with Vulkan 1.1.


First, the specifications for both Vulkan 1.1 and SPIR-V 1.3 have been published. We will get into the details of those two standards later. Second, a suite of conformance tests has also been included with this release, which helps prevent an implementation bug from being an implied API that software relies upon ad-infinitum. Third, several developer tools have been released, mostly by LunarG, into the open-source ecosystem.

Fourth – conformant drivers. The following companies have Vulkan 1.1-certified drivers:


There are two new additions to the API:

The first is Protected Content. This allows developers to restrict access to rendering resources (DRM). Moving on!

The second is Subgroup Operations. We mentioned that they were added to SPIR-V back in 2016 when Microsoft announced HLSL Shader Model 6.0, and some of the instructions were available as OpenGL extensions. They are now a part of the core Vulkan 1.1 specification. This allows the individual threads of a GPU in a warp or wavefront to work together on specific instructions.


Shader compilers can use these intrinsics to speed up operations such as:

  • Finding the min/max of a series of numbers
  • Shuffle and/or copy values between lanes of a group
  • Adding several numbers together
  • Multiply several numbers together
  • Evaluate whether any, all, or which lanes of a group evaluate true

In other words, shader compilers can do more optimizations, which boosts the speed of several algorithms and should translate to higher performance when shader-limited. It also means that DirectX titles using Shader Model 6.0 should be able to compile into their Vulkan equivalents when using the latter API.


This leads us to SPIR-V 1.3. (We’ll circle back to Vulkan later.) SPIR-V is the shading language that Vulkan relies upon, which is based on a subset of LLVM. SPIR-V is the code that is actually run on the GPU hardware – Vulkan just deals with how to get this code onto the silicon as efficiently as possible. In a video game, this would be whatever code the developer chose to represent lighting, animation, particle physics, and almost anything else done on the GPU.

The Khronos Group is promoting that the SPIR-V ecosystem can be written in either GLSL, OpenCL C, or even HLSL. In other words, the developer will not need to rewrite their DirectX shaders to operate on Vulkan. This isn’t particularly new – Unity did this sort-of HLSL to SPIR-V conversion ever since they added Vulkan – but it’s good to mention that it’s a promoted workflow. OpenCL C will also be useful for developers who want to move existing OpenCL code into Vulkan on platforms where the latter is available but the former rarely is, such as Android.


Speaking of which, that’s exactly what Google, Codeplay, and Adobe are doing. Adobe wrote a lot of OpenCL C code for their Creative Cloud applications, and they want to move it elsewhere. This ended up being a case study for an OpenCL to Vulkan run-time API translation layer and the Clspv OpenCL C to SPIR-V compiler. The latter is open source, and the former might become open source in the future.

Now back to Vulkan.


The other major change with this new version is the absorption of several extensions into the core, 1.1 specification.

The first is Multiview, which allows multiple projections to be rendered at the same time, as seen in the GTX 1080 launch. This can be used for rendering VR, stereoscopic 3D, cube maps, and curved displays without extra draw calls.

The second is device groups, which allows multiple GPUs to work together.

The third allows data to be shared between APIs and even whole applications. The Khronos Group specifically mentions that Steam VR SDK uses this.

The fourth is 16-bit data types. While most GPUs operate on 32-bit values, it might be beneficial to pack data into 16-bit values in memory for algorithms that are limited by bandwidth. It also helps Vulkan be used in non-graphics workloads.

We already discussed HLSL support, but that’s an extension that’s now core.

The sixth extension is YCbCr support, which is required by several video codecs.

The last thing that I would like to mention is the Public Vulkan Ecosystem Forum. The Khronos Group has regularly mentioned that they want to get the open-source community more involved in reporting issues and collaborating on solutions. In this case, they are working on a forum where both members and non-members will collaborate, as well as the usual GitHub issues tab and so forth.

You can check out the details here.

The Khronos Group Releases SYCL 1.2.1

Subject: General Tech | December 10, 2017 - 06:51 PM |
Tagged: Khronos, SYCL, sycl 1.2, sycl 1.2.1, opencl 1.2, opencl

The specification for SYCL 1.2.1, which is based on OpenCL 1.2, has been finalized and released on the Khronos website. The describe it as a major update over the previous standard, SYCL 1.2, and it is. Since May 2015, when SYCL 1.2 was finalized, The Khronos Group added features from C++11, C++14, and C++17, including the ISO C++17 Parallel Standard Template Library (STL).


In other words, you can create C++17 Parallel STL applications with SYCL 1.2.1, single-source, that are able to offload to OpenCL 1.2 devices.

Beyond that, the specification changes also help machine learning. The Khronos Group mentions that Google’s TensorFlow supports SYCL, bringing the framework to OpenCL devices. They want to continue updating the specification in this area, along with Safety Critical applications, such as automotive. They also want to keep updating the standard with ISO C++ features. In other words? SYCL is being adopted, and they intend ongoing support to match.

You can read the press release at their website.

The Khronos Group Expands Presence in China

Subject: General Tech | November 26, 2017 - 09:19 PM |
Tagged: Khronos

The Khronos Group has added a couple of new partners from China: The China Academy of Information and Communication Technology (CAICT) and Tencent. The former is a research institute for China’s Ministry of Industry and Information Technology, which should significantly help adoption of open standards across several Chinese companies. The latter is a huge Chinese telecom with huge investments in software and hardware; for instance, they own about 40% of Epic Games, makers of Unreal Engine.


The goal of this is to gain a huge amount of conformant software using these APIs. China is a huge market in several ways; not only would this push the technology into several products and middleware, but it should also help contribute back from China to the international standards from The Khronos Group. If there’s something that could be done to help an implementation become conformant, then that line of communication should be open rather than just encouraging them to fork-away a semi-but-not-quite-compliant standard, which apparently was an issue with OpenCL.

You can read the official press release at their website.

The Khronos Group Releases OpenVX 1.2 Conformance Tests

Subject: General Tech | November 26, 2017 - 07:39 PM |
Tagged: Khronos, openvx, deep neural network, computer vision

OpenVX is an API that enables computer vision in a range of applications, from gesture tracking to surveillance to robotics. This version includes the neural network nodes (convolution, deconvolution, etc.) as well as import and export for compiling graphs offline. This is a part of the updated Adopters Program for OpenCX, which is, as usual for the Khronos Group, cross-platform and royalty-free.


Obviously, this only affects a subset of our readers directly, but cross-platform, royalty-free APIs for advanced computing functions will eventually lead to interesting technology. At the same time, for the developers in our audience, the tools are now available to test your code and hardware. The Khronos Group expects that early implementations will ship in 2018.

You can read the full press release at their website.

The Khronos Group Releases OpenGL 4.6

Subject: Graphics Cards | August 2, 2017 - 07:01 AM |
Tagged: spir-v, opengl, Khronos

While Vulkan has been getting a lot of mindshare recently, OpenGL is still in active development. This release, OpenGL 4.6, adds a bunch of extensions into the core specification, making them more reliably available to engines. There’s a lot of them this time, many of which seem to borrow design elements from the work done on Vulkan.


The headlining feature is SPIR-V support as an ARB extension, which frees OpenGL programs from having their shaders written in GLSL. Many engines write their shaders in HLSL and use a transpiler to generate the corresponding GLSL, which may not support all features. The extension might also help titles target both OpenGL and Vulkan, although I’m not sure why we would see a driver that supports OpenGL 4.6 but not Vulkan.

Another extension is GL_KHR_no_error, which tells graphics drivers that they do not need to generate errors at runtime. This will save a bit of driver overhead. GL_ARB_indirect_parameters also helps with CPU overhead by allowing draws to pass parameters to other GPU-initiated draws, although this is a bit out of my domain. Also, if you’re not working in SPIR-V, GL_KHR_parallel_shader_compile will allow the driver to compile your GLSL shaders across multiple worker threads.

NVIDIA has a beta driver for developers, which is a couple of versions back compared to their consumer version, so you don’t want to install it unless you intend on developing OpenGL 4.6 applications. Mesa says that they shouldn’t be too far behind.

Blender glTF 2.0 Exporter Published

Subject: General Tech | July 10, 2017 - 07:24 AM |
Tagged: Khronos, gltf, Blender

As we reported about a month ago, The Khronos Group has finalized glTF 2.0, which is a 3D format designed for whole scenes. Since then, Khronos have published an exporter for Blender that implements what appears to be all core features, as well as specular-gloss PBR (Extension), lights (Experimental), “materials common” (Experimental), and “materials displace” (Experimental). It is implemented as a whole bunch of Python scripts.


Apparently they provide their own PBR shader nodes for Cycles, rather than using the new Disney-based one in Blender 2.79. I’m not sure whether this was to make the export easier, or if development schedules just couldn’t align. Either way, both metallic/roughness and specular/gloss workflows have been provided, so that should make exporting either workflow relatively straight-forward.

Subject: General Tech
Manufacturer: The Khronos Group

An Data Format for Whole 3D Scenes

The Khronos Group has finalized the glTF 2.0 specification, and they recommend that interested parties integrate this 3D scene format into their content pipeline starting now. It’s ready.


glTF is a format to deliver 3D content, especially full scenes, in a compact and quick-loading data structure. These features differentiate glTF from other 3D formats, like Autodesk’s FBX and even the Khronos Group’s Collada, which are more like intermediate formats between tools, such as 3D editing software (ex: Maya and Blender) and game engines. They don’t see a competing format for final scenes that are designed to be ingested directly, quick and small.

glTF 2.0 makes several important changes.

The previous version of glTF was based on a defined GLSL material, which limited how it could be used, although it did align with WebGL at the time (and that spurred some early adoption). The new version switches to Physically Based Rendering (PBR) workflows to define their materials, which has a few advantages.

khronos-2017-PBR material model in glTF 2.0.jpg

First, PBR can represent a wide range of materials with just a handful of parameters. Rather than dictating a specific shader, the data structure can just... structure the data. The industry has settled on two main workflows, metallic-roughness and specular-gloss, and glTF 2.0 supports them both. (Metallic-roughness is the core workflow, but specular-gloss is provided as an extension, and they can be used together in the same scene. Also, during the briefing, I noticed that transparency was not explicitly mentioned in the slide deck, but the Khronos Group confirmed that it is stored as the alpha channel of the base color, and thus supported.) Because the format is now based on existing workflows, the implementation can be programmed in OpenGL, Vulkan, DirectX, Metal, or even something like a software renderer. In fact, Microsoft was a specification editor on glTF 2.0, and they have publicly announced using the format in their upcoming products.

The original GLSL material, from glTF 1.0, is available as an extension (for backward compatibility).

A second advantage of PBR is that it is lighting-independent. When you define a PBR material for an object, it can be placed in any environment and it will behave as expected. Noticeable, albeit extreme examples of where this would have been useful are the outdoor scenes of Doom 3, and the indoor scenes of Battlefield 2. It also simplifies asset creation. Some applications, like Substance Painter and Quixel, have artists stencil materials onto their geometry, like gold, rusted iron, and scuffed plastic, and automatically generate the appropriate textures. It also aligns well with deferred rendering, see below, which performs lighting as a post-process step and thus skip pixels (fragments) that are overwritten.


PBR Deferred Buffers in Unreal Engine 4 Sun Temple.
Lighting is applied to these completed buffers, not every fragment.

glTF 2.0 also improves support for complex animations by adding morph targets. Most 3D animations, beyond just moving, rotating, and scaling whole objects, are based on skeletal animations. This method works by binding vertexes to bones, and moving, rotating, and scaling a hierarchy of joints. This works well for humans, animals, hinges, and other collections of joints and sockets, and it was already supported in glTF 1.0. Morph targets, on the other hand, allow the artist to directly control individual vertices between defined states. This is often demonstrated with a facial animation, interpolating between smiles and frowns, but, in an actual game, this is often approximated with skeletal animations (for performance reasons). Regardless, glTF 2.0 now supports morph targets, too, letting the artists make the choice that best suits their content.

Speaking of performance, the Khronos Group is also promoting “enhanced performance” as a benefit of glTF 2.0. I asked whether they have anything to elaborate on, and they responded with a little story. While glTF 1.0 validators were being created, one of the engineers compiled a list of design choices that would lead to minor performance issues. The fixes for these were originally supposed to be embodied in a glTF 1.1 specification, but PBR workflows and Microsoft’s request to abstract the format away from GLSL lead to glTF 2.0, which is where the performance optimization finally ended up. Basically, there wasn’t just one or two changes that made a big impact; it was the result of many tiny changes that add up.

Also, the binary version of glTF is now a core feature in glTF 2.0.


The slide looks at the potential future of glTF, after 2.0.

Looking forward, the Khronos Group has a few items on their glTF roadmap. These did not make glTF 2.0, but they are current topics for future versions. One potential addition is mesh compression, via the Google Draco team, to further decrease file size of 3D geometry. Another roadmap entry is progressive geometry streaming, via Fraunhofer SRC, which should speed up runtime performance.

Yet another roadmap entry is “Unified Compression Texture Format for Transmission”, specifically Basis by Binomial, for texture compression that remains as small as possible on the GPU. Graphics processors can only natively operate on a handful of formats, like DXT and ASTC, so textures need to be converted when they are loaded by an engine. Often, when a texture is loaded at runtime (rather than imported by the editor) it will be decompressed and left in that state on the GPU. Some engines, like Unity, have a runtime compress method that converts textures to DXT, but the developer needs to explicitly call it and the documentation says it’s lower quality than the algorithm used by the editor (although I haven’t tested this). Suffices to say, having a format that can circumvent all of that would be nice.

Again, if you’re interested in adding glTF 2.0 to your content pipeline, then get started. It’s ready. Microsoft is doing it, too.