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.
Standards organizations exist to provide a safe space for competitors to cooperate for the good of all. In 2019, Khronos has seen powerful commercial incentives drawing us ever closer forsophisticated, multi-level cooperation, but also external dynamics trying to force the industry apart.