Draco is a glTF extension for mesh compression along with an open-source library developed by Google to compress and decompress 3D meshes to significantly reduce the size of 3D content. Cesium has been collaborating with Khronos and Google to make Draco a glTF extension, and you can now load Draco compressed models and 3D tilesets in Cesium. Learn more about Draco, how it works and what it has to offer.
glTF continues to gain strong industry momentum with new support from major players including Facebook, Adobe, Epic, and Unity, in addition to the ongoing support from the grassroots open-source community. 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. Khronos has released new glTF testing tools, samples, and exporters to support this growing ecosystem.
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.
New functionality in Vulkan 1.1 includes Subgroup Operations that enable highly-efficient sharing and manipulation of data between multiple tasks running in parallel on a GPU. Khronos member and guest author Neil Henning (@sheredom), Principal Software Engineer, for Vulkan & SPIR-V at Codeplay Software has written an in-depth tutorial on how to use this new feature. Head on over to the Khronos blog and check out the tutorial. Feedback is welcome.
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. 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 Khronos does. There are two ways a Khronos standard can be extended: Vendor Extensions and Khronos Extensions. Read on to learn how both of these work within Khronos.
Authoring content for a new file format can be exciting, liberating, and at the same time scary. To be the most efficient and avoid frustration, it helps to understand the format's requirements. To help achieve this, Patrick Ryan from Microsoft has created a walk through following several paths for authoring content in the glTF format as well as outlining specific settings to maximize your success. Patrick touches on both free and commercial software packages to ensure everyone has a path into glTF. Let's get going... check out this glTF how-to.
There is a wide range of open-source deep learning training networks available today offering researchers and designers plenty of choice when they are setting up their project. Caffe, Tensorflow, Chainer, Theano, Caffe2, the list goes on and is getting longer all the time. This diversity is great for encouraging innovation, as the different approaches taken by the various frameworks make it possible to access a very wide range of capabilities, and, of course, to add functionality that’s then given back to the community. This helps to drive the virtuous cycle of innovation.
The Khronos Group is about to release a new standard method of moving trained neural networks among frameworks, and between frameworks and inference engines. The new standard is the Neural Network Exchange Format (NNEF™); it has been in design for over a year and will be available to the public by the end of 2017. Learn more about NNEF and the upcoming released in the Khronos blog post.
PerfDoc is a Vulkan layer which aims to validate applications against the Mali Application Developer Best Practices Guide. Just like the LunarG validation layers, this layer tracks your application and attempts to find API usage which is discouraged. PerfDoc focuses on checks which can be done up-front, and checks which can portably run on all platforms which support Vulkan. The intended use of PerfDoc is to be used during development to catch potential performance issues early. The layer will run on any Vulkan implementation, so Mali-related optimizations can be found even when doing bringup on desktop platforms. Just like Vulkan validation layers, errors are reported either through VK_EXT_debug_report to the application as callbacks, or via console/logcat if enabled. Dynamic checking (i.e. profiling) of how an application is behaving in run-time is not currently in the scope of PerfDoc. Some heuristics in PerfDoc are based on "arbitrary limits" in case where there is no obvious limit to use. These values can be tweaked later via config files if needed. Some checks which are CPU intensive (index scanning for example), can also be disabled by the config file. Please visit the GitHub repository for PerfDoc.