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. But, to an engineer looking for the shortest route to a product, they can sometimes feel restrictive, especially so when a technology is developing rapidly, driven forward by the engine of open source collaboration. Standards depend on stability and consensus, which takes time to develop. How can they keep up with a field like machine learning where it seems there is a new technique invented every day?
Is it possible to provide a stable standard that keeps existing hardware working, while still taking advantage of open source creativity and evolving the standard simultaneously with developments in the field? Let’s look at the two issues separately.
Khronos™ is all about standards. Balancing the need for a stable standard, while at the same time allowing technology advances to be rapidly exploited, is a big part of what we do. This has been there since the early days and finds expression in the extension mechanism. There are two ways a Khronos standard can be extended: by vendors (or groups of vendors), and by the Khronos Working Group. Vendor extensions are implemented and documented by member companies and, other than being registered with Khronos, nothing else is required. The user indicates which extensions are required by their application and can query the underlying hardware for compatibility.
Programmers who want the widest possible deployment platform can write their program to the core standard, and those that want the latest and greatest are able to create a platform that supports it. It’s simple, easy to administer, and effective at getting the latest techniques out and into the ecosystem without needing to wait for the rest of the world to catch up.
Khronos extensions are similar, but go through a more substantial ratification process. Usually, but not always, a Khronos extension indicates that the function will make it into the next version of the standard but bringing it in as an extension shortens the wait. The objective is to get emerging technologies out into the world as fast as possible without breaking apps that don’t need to go that route.
More recently, Khronos decided to harness the open source community in the development of standards. A search on GitHub will turn up dozens of Khronos projects, including some that contain the source of existing standards open for community revision in exactly the same way as any other open source project. Crucially, for standards that are transfer formats like glTF™ and NNEF™, the extension mechanism is available for the community to propose features that enable it to propagate new technologies for their own use at their own pace. Without the need to bring along hardware vendors, this opens the way for them to implement and move emerging technologies between frameworks in a timely and transparent way. All that is needed is to provide the implementation and register the extension with Khronos.
The Neural Network Exchange Format (NNEF) standard has been available for use since December 2017; it’s on Github and already has a nascent ecosystem of tools growing around it. Khronos invites open source community members to explore its capabilities and extend both the tools and the standard itself to meet their evolving needs.