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 Guidelines.
The Khronos® OpenCL™ working group recently created a new Tooling Subgroup with the aim of improving the tools ecosystem for this widely-used open standard for heterogeneous computation—in particular, boosting the development of tooling components that can be shared by multiple vendors. Subgroup members have been meeting regularly to coordinate the overall direction for OpenCL tools, with an emphasis on strengthening the development of tools in open source, particularly by encouraging collaboration between the OpenCL and LLVM communities.
To jointly advance accessibility of 3D geospatial content, The Khronos Group recently formalized a liaison with the Open Geospatial Consortium(OGC). One of the first victories of this collaboration between the computer graphics and geospatial communities is a new OGC Community Standard addressing massive scale 3D pioneered by longtime Khronos contributors, the Cesium team.
The Khronos Safety Critical Advisory Forum (KSCAF) gathers safety critical experts from a wide range of disciplines, such as transportation and medical imaging, who have experience developing software and products to widely adopting standards. The goal of KSCAF is to develop guidelines and recommendations for engineers creating open standard APIs within Khronos, and elsewhere in the industry, so that those standards can help streamline the product safety certification process. The Forum’s chair looks back on a successful 2018, with plans to expand in the new year ahead.
To further its goal of passing trained frameworks to embedded inference engines, the Khronos Group adds to its existing converters with two new bidirectional converters. Now available on the NNEF GitHub, these new tools enable easy conversion of trained models, including quantized models, between TensorFlow or Caffe2 formats and NNEF format.
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.
The demand for 3D content is growing quickly across markets. New formats, applications, and tools are being developed to keep up with the demand . TurboSquid has been eagerly watching the development of the glTF 2.0 specification and has now added full support for the format for its StemCell initiative, which standardizes how 3D models are built and makes buying a 3D model as easy as buying a stock photo.
In April, Khronos introduced the Safety Critical Advisory Forum was created in response to developers’ growing concerns and demands of functional safety standards on hardware and software. The advice and support that the forum provides to Khronos Working Groups directly contributes to the creation of SC APIs. Members and non-members can contribute in the forum, this post outlines the benefits of participation.
The Khronos™ OpenCL™ working group has today released a maintenance update to OpenCL 2.2 to consolidate numerous bug fixes and clarifications to make the specification more precisely defined and more easily understood. In this maintenance release, the OpenCL C specification has now also been put into open source.
Learn why one company chose the Khronos industry file format, glTF to create a searchable platform of interactive 3D content and find out how Sketchfab unlocked more than 150,000 glTF assets available for free download under Creative Commons licenses.
Facebook’s recent adoption of glTF 2.0 enables its users to place and see 3D content in their News Feeds, underscoring the social media platform’s plan to enable users to bring 3D objects and assets with them across AR, VR, mobile, and web experiences — using open standards. Facebook’s prominent support for glTF is already stimulating the creation of innovative tools to generate glTF content, such as Sony 3D Creator, Oculus Medium, and Foundry Modo.
As technology around artificial intelligence and autonomous driving advances, the need for safety critical systems also grows. Khronos Group has created a Safety Critical Advisory Forum and invites functional safety experts to join the group to advise and help develop open standards for the safety critical domain. By contributing your expertise to Khronos’ safety-critical work, you will enable Khronos and its API designers to deliver safety-critical APIs for a safer autonomous world.
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.
Standards make life easier, and we depend on them for more than we might realize — from knowing exactly how to drive any car, to knowing how to get hot or cold water from a faucet. When they fail us, the outcome can be comical or disastrous: non-standard plumbing, for instance, can result in an unexpected cold shower or a nasty scald. We need standards, and the entire computing world is built on them.