Subject: General Tech
Manufacturer: The Khronos Group

Don't Call It SPIR of the Moment

Vulkan 1.0 released a little over two years ago. The announcement, with conformant drivers, conformance tests, tools, and patch for The Talos Principle, made a successful launch for the Khronos Group. Of course, games weren’t magically three times faster or anything like that, but it got the API out there; it also redrew the line between game and graphics driver.

The Khronos Group repeats this “hard launch” with Vulkan 1.1.

khronos-2018-vulkan-logo.png

First, the specifications for both Vulkan 1.1 and SPIR-V 1.3 have been published. We will get into the details of those two standards later. Second, a suite of conformance tests has also been included with this release, which helps prevent an implementation bug from being an implied API that software relies upon ad-infinitum. Third, several developer tools have been released, mostly by LunarG, into the open-source ecosystem.

Fourth – conformant drivers. The following companies have Vulkan 1.1-certified drivers:

khronos-2018-vulkan-drivers.png

There are two new additions to the API:

The first is Protected Content. This allows developers to restrict access to rendering resources (DRM). Moving on!

The second is Subgroup Operations. We mentioned that they were added to SPIR-V back in 2016 when Microsoft announced HLSL Shader Model 6.0, and some of the instructions were available as OpenGL extensions. They are now a part of the core Vulkan 1.1 specification. This allows the individual threads of a GPU in a warp or wavefront to work together on specific instructions.

khronos-2018-vulkan-subgroup.png

Shader compilers can use these intrinsics to speed up operations such as:

  • Finding the min/max of a series of numbers
  • Shuffle and/or copy values between lanes of a group
  • Adding several numbers together
  • Multiply several numbers together
  • Evaluate whether any, all, or which lanes of a group evaluate true

In other words, shader compilers can do more optimizations, which boosts the speed of several algorithms and should translate to higher performance when shader-limited. It also means that DirectX titles using Shader Model 6.0 should be able to compile into their Vulkan equivalents when using the latter API.

khronos-2018-vulkan-spirv.png

This leads us to SPIR-V 1.3. (We’ll circle back to Vulkan later.) SPIR-V is the shading language that Vulkan relies upon, which is based on a subset of LLVM. SPIR-V is the code that is actually run on the GPU hardware – Vulkan just deals with how to get this code onto the silicon as efficiently as possible. In a video game, this would be whatever code the developer chose to represent lighting, animation, particle physics, and almost anything else done on the GPU.

The Khronos Group is promoting that the SPIR-V ecosystem can be written in either GLSL, OpenCL C, or even HLSL. In other words, the developer will not need to rewrite their DirectX shaders to operate on Vulkan. This isn’t particularly new – Unity did this sort-of HLSL to SPIR-V conversion ever since they added Vulkan – but it’s good to mention that it’s a promoted workflow. OpenCL C will also be useful for developers who want to move existing OpenCL code into Vulkan on platforms where the latter is available but the former rarely is, such as Android.

khronos-2018-vulkan-opencl.png

Speaking of which, that’s exactly what Google, Codeplay, and Adobe are doing. Adobe wrote a lot of OpenCL C code for their Creative Cloud applications, and they want to move it elsewhere. This ended up being a case study for an OpenCL to Vulkan run-time API translation layer and the Clspv OpenCL C to SPIR-V compiler. The latter is open source, and the former might become open source in the future.

Now back to Vulkan.

khronos-2018-vulkan-extensions.png

The other major change with this new version is the absorption of several extensions into the core, 1.1 specification.

The first is Multiview, which allows multiple projections to be rendered at the same time, as seen in the GTX 1080 launch. This can be used for rendering VR, stereoscopic 3D, cube maps, and curved displays without extra draw calls.

The second is device groups, which allows multiple GPUs to work together.

The third allows data to be shared between APIs and even whole applications. The Khronos Group specifically mentions that Steam VR SDK uses this.

The fourth is 16-bit data types. While most GPUs operate on 32-bit values, it might be beneficial to pack data into 16-bit values in memory for algorithms that are limited by bandwidth. It also helps Vulkan be used in non-graphics workloads.

We already discussed HLSL support, but that’s an extension that’s now core.

The sixth extension is YCbCr support, which is required by several video codecs.

The last thing that I would like to mention is the Public Vulkan Ecosystem Forum. The Khronos Group has regularly mentioned that they want to get the open-source community more involved in reporting issues and collaborating on solutions. In this case, they are working on a forum where both members and non-members will collaborate, as well as the usual GitHub issues tab and so forth.

You can check out the details here.

The Khronos Group Releases OpenGL 4.6

Subject: Graphics Cards | August 2, 2017 - 07:01 AM |
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.

khronos-2017-logo-OpenGL_500px_June16.png

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.

Podcast #450 - AMD Ryzen, AMD EPYC, AMD Threadripper, AMD Vega, and more non AMD news!

Subject: Editorial | May 18, 2017 - 11:46 AM |
Tagged: youtube tv, western digital, video, Vega, Threadripper, spir-v, ryzen, podcast, opencl, Google VR, EPYC, Core i9, battletech, amd

PC Perspective Podcast #450 - 05/18/17

Join us for AMD Announcments, Core i9 leaks, OpenCL updates, and more!

You can subscribe to us through iTunes and you can still access it directly through the RSS page HERE.

The URL for the podcast is: http://pcper.com/podcast - Share with your friends!

Hosts: Ryan Shrout, Jeremy Hellstrom, Josh Walrath, Allyn Malventano

Peanut Gallery: Alex Lustenberg

Program length: 1:20:36

Podcast topics of discussion:

  1. Week in Review:
  2. News items of interest:
  3. Hardware/Software Picks of the Week
    1. Ryan: Gigabit LTE please hurry
    2. Allyn: TriboTEX (nanotech engine oil additive)
  4. Closing/outro

Subscribe to the PC Perspective YouTube Channel for more videos, reviews and podcasts!!

 

 

Source:

Khronos Group Published Finalized OpenCL 2.2 & SPIR-V 1.2

Subject: General Tech | May 16, 2017 - 09:00 AM |
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.

OpenCL_Logo.png

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.

The final OpenCL 2.2 and SPIR-V 1.2 specs are available now, and on GitHub for the first time.

DirectX Intermediate Language Announced... via GitHub

Subject: Graphics Cards | January 27, 2017 - 09:19 PM |
Tagged: microsoft, DirectX, llvm, dxil, spir-v, vulkan

Over the holidays, Microsoft has published the DirectX Shader Compiler onto GitHub. The interesting part about this is that it outputs HLSL into DirectX Intermediate Language (DXIL) bytecode, which can be ingested by GPU drivers and executed on graphics devices. The reason why this is interesting is that DXIL is based on LLVM, which might start to sound familiar if you have been following along with The Khronos Group and their announcements regarding Vulkan, OpenCL, and SPIR-V.

As it turns out, they were on to something, and Microsoft is working on a DirectX analogue of it.

microsoft-2015-directx12-logo.jpg

The main advantage of LLVM-based bytecode is that you can eventually support multiple languages (and the libraries of code developed in them). When SPIR-V was announced with Vulkan, the first thing that came to my mind was compiling to it from HLSL, which would be useful for existing engines, as they are typically written in HLSL and transpiled to the target platform when used outside of DirectX (like GLSL for OpenGL). So, in Microsoft’s case, it would make sense that they start there (since they own the thing) but I doubt that is the end goal. The most seductive outcome for game engine developers would be single-source C++, but there is a lot of steps between there and here.

Another advantage, albeit to a lesser extent, is that you might be able to benefit from performance optimizations, both on the LLVM / language side as well as on the driver’s side.

According to their readme, the minimum support will be HLSL Shader Model 6. This is the most recent shading model, and it introduces some interesting instructions, typically for GPGPU applications, that allow multiple GPU threads to interact, like balloting. Ironically, while DirectCompute and C++AMP don’t seem to be too popular, this would nudge DirectX 12 into a somewhat competent GPU compute API.

DXIL support is limited to Windows 10 Build 15007 and later, so you will need to either switch one (or more) workstation(s) to Insider, or wait until it launches with the Creators Update (unless something surprising holds it back).