Subject: General Tech | December 10, 2017 - 06:51 PM | Scott Michaud
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.
Subject: General Tech | November 26, 2017 - 09:19 PM | Scott Michaud
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.
Subject: General Tech | November 26, 2017 - 07:39 PM | Scott Michaud
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.
Subject: Graphics Cards | August 2, 2017 - 07:01 AM | Scott Michaud
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.
Subject: General Tech | July 10, 2017 - 07:24 AM | Scott Michaud
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.
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.
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.
Subject: General Tech | May 25, 2017 - 11:12 AM | Ryan Shrout
Tagged: vulkan, video, Surface Pro, SolidScale, seasonic, ps4 pro, podcast, opencl, micon, macbook pro, Khronos, fsp, Eisbaer, Chromebook, Alphacool, aimpad
PC Perspective Podcast #451 - 05/25/17
Join us for talk about the wew Surface Pro, analog keyboards, water cooled PSUs and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the iTunes Store (audio only)
- Google Play - Subscribe to our audio podcast directly through Google Play!
- RSS - Subscribe through your regular RSS reader (audio only)
- MP3 - Direct download link to the MP3 file
Hosts: Ryan Shrout, Jeremy Hellstrom, Josh Walrath, Allyn Malventano
Peanut Gallery: Alex Lustenberg, Jim Tanous, Ken Addison
Podcast topics of discussion:
The Right People to Interview
Last week, we reported that OpenCL’s roadmap would be merging into Vulkan, and OpenCL would, starting at some unspecified time in the future, be based “on an extended version of the Vulkan API”. This was based on quotes from several emails between myself and the Khronos Group.
Since that post, I had the opportunity to have a phone interview with Neil Trevett, president of the Khronos Group and chairman of the OpenCL working group, and Tom Olson, chairman of the Vulkan working group. We spent a little over a half hour going over Neil’s International Workshop on OpenCL (IWOCL) presentation, discussing the decision, and answering a few lingering questions. This post will present the results of that conference call in a clean, readable way.
First and foremost, while OpenCL is planning to merge into the Vulkan API, the Khronos Group wants to make it clear that “all of the merging” is coming from the OpenCL working group. The Vulkan API roadmap is not affected by this decision. Of course, the Vulkan working group will be able to take advantage of technologies that are dropping into their lap, but those discussions have not even begun yet.
Neil: Vulkan has its mission and its roadmap, and it’s going ahead on that. OpenCL is doing all of the merging. We’re kind-of coming in to head in the Vulkan direction.
Does that mean, in the future, that there’s a bigger wealth of opportunity to figure out how we can take advantage of all this kind of mutual work? The answer is yes, but we haven’t started those discussions yet. I’m actually excited to have those discussions, and are many people, but that’s a clarity. We haven’t started yet on how Vulkan, itself, is changed (if at all) by this. So that’s kind-of the clarity that I think is important for everyone out there trying to understand what’s going on.
Tom also prepared an opening statement. It’s not as easy to abbreviate, so it’s here unabridged.
Tom: I think that’s fair. From the Vulkan point of view, the way the working group thinks about this is that Vulkan is an abstract machine, or at least there’s an abstract machine underlying it. We have a programming language for it, called SPIR-V, and we have an interface controlling it, called the API. And that machine, in its full glory… it’s a GPU, basically, and it’s got lots of graphics functionality. But you don’t have to use that. And the API and the programming language are very general. And you can build lots of things with them. So it’s great, from our point of view, that the OpenCL group, with their special expertise, can use that and leverage that. That’s terrific, and we’re fully behind it, and we’ll help them all we can. We do have our own constituency to serve, which is the high-performance game developer first and foremost, and we are going to continue to serve them as our main mission.
So we’re not changing our roadmap so much as trying to make sure we’re a good platform for other functionality to be built on.
Neil then went on to mention that the decision to merge OpenCL’s roadmap into the Vulkan API took place only a couple of weeks ago. The purpose of the press release was to reach OpenCL developers and get their feedback. According to him, they did a show of hands at the conference, with a room full of a hundred OpenCL developers, and no-one was against moving to the Vulkan API. This gives them confidence that developers will accept the decision, and that their needs will be served by it.
Next up is the why. Read on for more.
It Started with an OpenCL 2.2 Press Release
Update (May 18 @ 4pm EDT): A few comments across the internet believes that the statements from The Khronos Group were inaccurately worded, so I emailed them yet again. The OpenCL working group has released yet another statement:
OpenCL is announcing that their strategic direction is to support CL style computing on an extended version of the Vulkan API. The Vulkan group is agreeing to advise on the extensions.
In other words, this article was and is accurate. The Khronos Group are converging OpenCL and Vulkan into a single API: Vulkan. There was no misinterpretation.
Original post below
Earlier today, we published a news post about the finalized specifications for OpenCL 2.2 and SPIR-V 1.2. This was announced through a press release that also contained an odd little statement at the end of the third paragraph.
We are also working to converge with, and leverage, the Khronos Vulkan API — merging advanced graphics and compute into a single API.
This statement seems to suggest that OpenCL and Vulkan are expecting to merge into a single API for compute and graphics at some point in the future. This seemed like a huge announcement to bury that deep into the press blast, so I emailed The Khronos Group for confirmation (and any further statements). As it turns out, this interpretation is correct, and they provided a more explicit statement:
The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute.
This statement adds a new claim: The Khronos Group plans to merge OpenCL into Vulkan, specifically, at some point in the future. Making the move in this direction, from OpenCL to Vulkan, makes sense for a handful of reasons, which I will highlight in my analysis, below.
Going Vulkan to Live Long and Prosper?
The first reason for merging OpenCL into Vulkan, from my perspective, is that Apple, who originally created OpenCL, still owns the trademarks (and some other rights) to it. The Khronos Group licenses these bits of IP from Apple. Vulkan, based on AMD’s donation of the Mantle API, should be easier to manage from the legal side of things.
The second reason for going in that direction is the actual structure of the APIs. When Mantle was announced, it looked a lot like an API that wrapped OpenCL with a graphics-specific layer. Also, Vulkan isn’t specifically limited to GPUs in its implementation.
Aside: When you create a device queue, you can query the driver to see what type of device it identifies as by reading its VkPhysicalDeviceType. Currently, as of Vulkan 1.0.49, the options are Other, Integrated GPU, Discrete GPU, Virtual GPU, and CPU. While this is just a clue, to make it easier to select a device for a given task, and isn’t useful to determine what the device is capable of, it should illustrate that other devices, like FPGAs, could support some subset of the API. It’s just up to the developer to check for features before they’re used, and target it at the devices they expect.
If you were to go in the other direction, you would need to wedge graphics tasks into OpenCL. You would be creating Vulkan all over again. From my perspective, pushing OpenCL into Vulkan seems like the path of least resistance.
The third reason (that I can think of) is probably marketing. DirectX 12 isn’t attempting to seduce FPGA developers. Telling a game studio to program their engine on a new, souped-up OpenCL might make them break out in a cold sweat, even if both parties know that it’s an evolution of Vulkan with cross-pollination from OpenCL. OpenCL developers, on the other hand, are probably using the API because they need it, and are less likely to be shaken off.
What OpenCL Could Give Vulkan (and Vice Versa)
From the very onset, OpenCL and Vulkan were occupying similar spaces, but there are some things that OpenCL does “better”. The most obvious, and previously mentioned, element is that OpenCL supports a wide range of compute devices, such as FPGAs. That’s not the limit of what Vulkan can borrow, though, although it could make for an interesting landscape if FPGAs become commonplace in the coming years and decades.
Personally, I wonder how SYCL could affect game engine development. This standard attempts to guide GPU- (and other device-) accelerated code into a single-source, C++ model. For over a decade, Tim Sweeney of Epic Games has talked about writing engines like he did back in the software-rendering era, but without giving up the ridiculous performance (and efficiency) provided by GPUs.
The reason for bringing up this anecdote is because, if OpenCL is moving into Vulkan, and SYCL is still being developed, then it seems likely that SYCL will eventually port into Vulkan. If this is the case, then future game engines can gain benefits that I was striving toward without giving up access to fixed-function features, like hardware rasterization. If Vulkan comes to web browsers some day, it would literally prune off every advantage I was hoping to capture, and it would do so with a better implementation.
More importantly, SYCL is something that Microsoft cannot provide with today’s DirectX.
Admittedly, it’s hard to think of something that OpenCL can acquire from Vulkan, besides just a lot more interest from potential developers. Vulkan was already somewhat of a subset of OpenCL that had graphics tasks (cleanly) integrated over top of it. On the other hand, OpenCL has been struggling to acquire mainstream support, so that could, in fact, be Vulkan’s greatest gift.
The Khronos Group has not provided a timeline for this change. It’s just a roadmap declaration.
Subject: General Tech | May 16, 2017 - 09:00 AM | Scott Michaud
Tagged: spir-v, opencl, Khronos
Aligning with the start of the International Workshop on OpenCL (IWOCL) 2017 in Toronto, Ontario, Canada, The Khronos Group has published the finalized specification for OpenCL 2.2 and SPIR-V 1.2. The headlining feature for this release is the OpenCL C++ kernel language, which SPIR-V 1.2 fully supports. Kernels are the portion of code that execute on the compute devices, such as GPUs, FPGAs, super computers, multi-core CPUs, and so forth.
The OpenCL C++ kernel language is a subset of the C++14 standard, bringing many of its benefits to these less-general devices. Classes help data and code to be more tightly integrated. Templates help define logic in a general way for whatever data type implements whatever it requires, which is useful for things like custom containers. Lambda expressions make it easy to write one-off methods, rather than forcing the developer to name something that will only be used once, like comparing two data types for a special sort in one specific spot of code.
Exposing these features to the OpenCL device also enables The Khronos Group to further the SYCL standard, which aims for “single-source” OpenCL development. Having the code that executes on OpenCL-compatible devices contain roughly the same features as the host code is kind-of necessary to let them be written together, rather than exist as two pools.