Podcast #442 - ARM DynamIQ, Optane Launch, Gigabit LTE, Vulkan

Subject: Editorial | March 23, 2017 - 12:26 PM |
Tagged: Yoga Book, vulkan, topre, snapdragon 835, SC17, qualcomm, podcast, Optane, LG 32UD99, Lenovo, Gigabit LTE, evga, DynamIQ, arm

PC Perspective Podcast #442 - 03/23/17

Join us for Topre and CORSAIR Keyboards, ARM DynamIQ, Optane Launch, EVGA 4K gaming laptop, 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, Allyn Malventano, Ken Addison

Program length: 1:35:25

 

Source:

OS Limitations of Vulkan Multi-GPU Support

Subject: Graphics Cards | March 21, 2017 - 07:47 PM |
Tagged: windows 10, vulkan, sli, multi-gpu, crossfire

Update (March 22nd @ 3:50pm EDT): And the Khronos Group has just responded to my follow-up questions. LDA has existed since Windows Vista, at the time for assisting with SLI and Crossfire support. Its implementation has changed in Windows 10, but that's not really relevant for Vulkan's multi-GPU support. To prove this, they showed LDA referenced in a Windows 8.1 MSDN post.

In short:

Vulkan's multi-GPU extensions can be used on Windows 7 and Windows 8.x. The exact process will vary from OS to OS, but the GPU vendor can implement these extensions if they choose, and LDA mode isn't exclusive to Windows 10.

 

Update (March 21st @ 11:55pm EDT): I came across a Microsoft Support page that discusses issues with LDA in Windows 7, so it seems like that functionality isn't limited to WDDM 2.0 and Windows 10. (Why have a support page otherwise?) Previously, I looked up an MSDN article that had it listed as a WDDM 2.0 feature, so I figured DSOGaming's assertion that it was introduced with WDDM 2.0 was correct.

As such, LDA might not require a GPU vendor's implementation at all. It'll probably be more clear when the Khronos Group responds to my earlier request, though.

That said, we're arguing over how much a GPU vendor needs to implement; either way, it will be possible to use the multi-GPU extensions in Windows 7 and Windows 8.x if the driver supports it.

Update (March 21st @ 7:30pm EDT): The Khronos Group has just released their statement. It's still a bit unclear, and I've submit another request for clarification.

Specifically, the third statement:

If an implementation on Windows does decide to use LDA mode, it is NOT tied to Windows 10. LDA mode has been available on many versions of Windows, including Windows 7 and 8.X.

... doesn't elaborate what is required for LDA mode on Windows outside of 10. (It could be Microsoft-supported, vendor-supported, or something else entirely.) I'll update again when that information is available. For now, it seems like the table, below, should actually look something like this:

  Implicit Multi-GPU
(LDA Implicit)
Explicit Multi-GPU
(LDA Explicit)
Unlinked Multi-GPU
(MDA)
Windows 7 Requires GPU Vendor
LDA Implementation?

(Or Equivalent)
Requires GPU Vendor
LDA Implementation?

(Or Equivalent)
Windows 8.1 Requires GPU Vendor
LDA Implementation?

(Or Equivalent)
Requires GPU Vendor
LDA Implementation?

(Or Equivalent)
Windows 10
macOS Apple doesn't allow the Vulkan API to ship in graphics drivers.
At all.
Linux / etc.

... but we will update, again, should this be inaccurate.

Update (March 20th @ 3:50pm EDT): The Khronos Group has just responded that the other posts are incorrect. They haven't yet confirmed whether this post (which separates "device groups" from the more general "multi-GPU in Vulkan") is correct, though, because they're preparing an official statement. We'll update when we have more info.

Original Post Below (March 19th @ 9:36pm EDT)

A couple of days ago, some sites have noticed a bullet point that claims Windows-based GPU drivers will need WDDM in “linked display adapter” mode for “Native multi-GPU support for NVIDIA SLI and AMD Crossfire platforms” on Vulkan. This note came from an official slide deck by the Khronos Group, which was published during the recent Game Developers Conference, GDC 2017. The concern is that “linked display adapter” mode is a part of WDDM 2.0, which is exclusive to Windows 10.

This is being interpreted as “Vulkan does not support multi-GPU under Windows 7 or 8.x”.

khronos-2017-vulkan-alt-logo.png

I reached out to the Khronos Group for clarification, but I’m fairly sure I know what this does (and doesn’t) mean. Rather than starting with a written out explanation in prose, I will summarize it into a table, below, outlining what is possible on each platform. I will then elaborate below that.

  Implicit Multi-GPU
(LDA Implicit)
Explicit Multi-GPU
(LDA Explicit)
Unlinked Multi-GPU
(MDA)
Windows 7    
Windows 8.1    
Windows 10
macOS Apple doesn't allow the Vulkan API to ship in graphics drivers.
At all.
Linux / etc.

So the good news is that it’s possible for a game developer to support multi-GPU (through what DirectX 12 would call MDA) on Windows 7 and Windows 8.x; the bad news is that no-one might bother with the heavy lifting. Linked display adapters allow the developer to assume that all GPUs are roughly the same performance, have the same amount of usable memory, and can be accessed through a single driver interface. On top of these assumptions, device groups also hide some annoying and tedious work inside the graphics driver, like producing a texture on one graphics card and quickly giving it to another GPU for rendering.

Basically, if the developer will go through the trouble of supporting AMD + NVIDIA or discrete GPU + integrated GPU systems, then they can support Windows 7 / 8.x in multi-GPU as well. Otherwise? Your extra GPUs will be sitting out unless you switch to DirectX 11 or OpenGL (or you use it for video encoding or something else outside the game).

On the other hand, this limitation might pressure some developers to support unlinked multi-GPU configurations. There are some interesting possibilities, including post-processing, GPGPU tasks like AI visibility and physics, and so forth, which might be ignored in titles whose developers were seduced by the simplicity of device groups. On the whole, device groups was apparently a high-priority request by game developers, and its inclusion will lead to more multi-GPU content. Developers who can justify doing it themselves, though, now have another reason to bother re-inventing a few wheels.

Or... you could just use Linux. That works, too.

Again, we are still waiting on the Khronos Group to confirm this story. See the latest update, above.

Linked Multi-GPU Arrives... for Developers

The Khronos Group has released the Vulkan 1.0.42.0 specification, which includes experimental (more on that in a couple of paragraphs) support for VR enhancements, sharing resources between processes, and linking similar GPUs. This spec was released alongside a LunarG SDK and NVIDIA drivers, which are intended for developers, not gamers, that fully implement these extensions.

I would expect that the most interesting feature is experimental support for linking similar GPUs together, similar to DirectX 12’s Explicit Linked Multiadapter, which Vulkan calls a “Device Group”. The idea is that the physical GPUs hidden behind this layer can do things like share resources, such as rendering a texture on one GPU and consuming it in another, without the host code being involved. I’m guessing that some studios, like maybe Oxide Games, will decide to not use this feature. While it’s not explicitly stated, I cannot see how this (or DirectX 12’s Explicit Linked mode) would be compatible in cross-vendor modes. Unless I’m mistaken, that would require AMD, NVIDIA, and/or Intel restructuring their drivers to inter-operate at this level. Still, the assumptions that could be made with grouped devices are apparently popular with enough developers for both the Khronos Group and Microsoft to bother.

microsoft-dx12-build15-linked.png

A slide from Microsoft's DirectX 12 reveal, long ago.

As for the “experimental” comment that I made in the introduction... I was expecting to see this news around SIGGRAPH, which occurs in late-July / early-August, alongside a minor version bump (to Vulkan 1.1).

I might still be right, though.

The major new features of Vulkan 1.0.42.0 are implemented as a new classification of extensions: KHX. In the past, vendors, like NVIDIA and AMD, would add new features as vendor-prefixed extensions. Games could query the graphics driver for these abilities, and enable them if available. If these features became popular enough for multiple vendors to have their own implementation of it, a committee would consider an EXT extension. This would behave the same across all implementations (give or take) but not be officially adopted by the Khronos Group. If they did take it under their wing, it would be given a KHR extension (or added as a required feature).

The Khronos Group has added a new layer: KHX. This level of extension sits below KHR, and is not intended for production code. You might see where this is headed. The VR multiview, multi-GPU, and cross-process extensions are not supposed to be used in released video games until they leave KHX status. Unlike a vendor extension, the Khronos Group wants old KHX standards to drop out of existence at some point after they graduate to full KHR status. It’s not something that NVIDIA owns and will keep it around for 20 years after its usable lifespan just so old games can behave expectedly.

khronos-group-logo.png

How long will that take? No idea. I’ve already mentioned my logical but uneducated guess a few paragraphs ago, but I’m not going to repeat it; I have literally zero facts to base it on, and I don’t want our readers to think that I do. I don’t. It’s just based on what the Khronos Group typically announces at certain trade shows, and the length of time since their first announcement.

The benefit that KHX does bring us is that, whenever these features make it to public release, developers will have already been using it... internally... since around now. When it hits KHR, it’s done, and anyone can theoretically be ready for it when that time comes.

Podcast #438 - Vulkan, Logitech G213, Ryzen Preorders, and more!

Subject: Editorial | February 23, 2017 - 12:16 PM |
Tagged: podcast, vulkan, ryzen, qualcomm, Qt, mesh, g213, eero, corsair, bulldog

PC Perspective Podcast #438 - 02/23/17

Join us for Vulkan one year later, Logitech G213 Keyboard, eero home mesh networking, Ryzen Pre Orders, 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: Allyn Malventano, Ken Addison, Josh Walrath, Jermey Hellstrom

Program length: 0:58:01

Podcast topics of discussion:
  1. Week in Review:
  2. News items of interest:
  3. Hardware/Software Picks of the Week
    1. Allyn: SS64.com - Nifty programmer's reference for scripting, web, db
    2. Ken: Dell refurbished XPS 13
  4. Closing/outro
 

Source:

The Qt Company Announces Qt 3D Studio

Subject: General Tech | February 20, 2017 - 04:46 PM |
Tagged: vulkan, Qt, nvidia

NVIDIA has just donated their entire DRIVE Design Studio to The Qt Company, who will form it into Qt 3D Studio. This product will be a visual editor for 3D user interfaces, where layers of 2D and 3D objects can be created, animated, and integrated into C++ applications. It will take them a little while to clean it up for public consumption, but it will eventually be available under the commercial / open-source dual-license that users of Qt are accustomed to.

If you’re not familiar with the Qt Framework, then, basically, think of a cross-platform, open-source alternative to the .NET framework, although it is based in unmanaged C++. (It also competes with GTK+. This isn’t a major point, but I would like it to be clear that it’s not a two-person race between one proprietary and one open-source player.) When AMD updated their graphics drivers to Crimson Edition, and flaunted huge speed-ups, it was mostly because they switched the control panel's UI framework from .NET to Qt.

As an aside, The Qt Company joined the Khronos Group on the day that Vulkan launched, which was almost exactly a year ago, and they are actively working on integrating the API in their framework. Combined with today’s announcement, it’s not hard to imagine how much easier it will be, some day, to create efficient and beautiful UIs.

Update: Speaking of which, The Qt Company is apparently planning to release Vulkan support with Qt 5.10.

Manufacturer: PC Perspective

Living Long and Prospering

The open fork of AMD’s Mantle, the Vulkan API, was released exactly a year ago with, as we reported, a hard launch. This meant public, but not main-branch drivers for developers, a few public SDKs, a proof-of-concept patch for The Talos Principle, and, of course, the ratified specification. This sets up the API to find success right out of the gate, and we can now look back over the year since.

khronos-2017-vulkan-alt-logo.png

Thor's hammer, or a tempest in a teapot?

The elephant in the room is DOOM. This game has successfully integrated the API and it uses many of its more interesting features, like asynchronous compute. Because the API is designed in a sort-of “make a command, drop it on a list” paradigm, the driver is able to select commands based on priority and available resources. AMD’s products got a significant performance boost, relative to OpenGL, catapulting their Fury X GPU up to the enthusiast level that its theoretical performance suggested.

Mobile developers have been picking up the API, too. Google, who is known for banishing OpenCL from their Nexus line and challenging OpenGL ES with their Android Extension Pack (later integrated into OpenGL ES with version 3.2), has strongly backed Vulkan. The API was integrated as a core feature of Android 7.0.

On the engine and middleware side of things, Vulkan is currently “ready for shipping games” as of Unreal Engine 4.14. It is also included in Unity 5.6 Beta, which is expected for full release in March. Frameworks for emulators are also integrating Vulkan, often just to say they did, but sometimes to emulate the quirks of these system’s offbeat graphics co-processors. Many other engines, from Source 2 to Torque 3D, have also announced or added Vulkan support.

Finally, for the API itself, The Khronos Group announced (pg 22 from SIGGRAPH 2016) areas that they are actively working on. The top feature is “better” multi-GPU support. While Vulkan, like OpenCL, allows developers to enumerate all graphics devices and target them, individually, with work, it doesn’t have certain mechanisms, like being able to directly ingest output from one GPU into another. They haven’t announced a timeline for this.

Vulkan is not extinct, in fact it might be about to erupt

Subject: General Tech | February 15, 2017 - 01:29 PM |
Tagged: vulkan, Intel, Intel Skylake, kaby lake

The open source API, Vulkan, just received a big birthday present from Intel as they added official support on their Skylake and Kaby Lake CPUs under Windows 10.  We have seen adoption of this API from a number of game engine designers, Unreal Engine and Unity have both embraced it, the latest DOOM release was updated to support Vulkan and there is even a Nintendo 64 renderer which runs on it.  Ars Technica points out that both AMD and NVIDIA have been supporting this API for a while and that we can expect to see Android implementations of this close to the metal solution in the near future.

khronos-2016-vulkanlogo2.png

"After months in beta, Intel's latest driver for its integrated GPUs (version 15.45.14.4590) adds support for the low-overhead Vulkan API for recent GPUs running in Windows 10. The driver supports HD and Iris 500- and 600-series GPUs, the ones that ship with 6th- and 7th-generation Skylake and Kaby Lake processors."

Here is some more Tech News from around the web:

Tech Talk

Source: Ars Technica

WebKit Proposal for WebGPU

Subject: General Tech | February 8, 2017 - 10:46 PM |
Tagged: webkit, webgpu, metal, vulkan, webgl

Apple’s WebKit team has just announced their proposal for WebGPU, which competes with WebGL to provide graphics and GPU compute to websites. Being from Apple, it is based on the Metal API, so it has a lot of potential, especially as a Web graphics API.

Okay, so I have mixed feelings about this announcement.

apple-2017-webkit-logo.png

First, and most concerning, is that Apple has attempted to legally block open standards in the past. For instance, when The Khronos Group created WebCL based on OpenCL, which Apple owns the trademark and several patents to, Apple shut the door on extending their licensing agreement to the new standard. If the W3C considers Apple’s proposal, they should be really careful about what legal control they allow Apple to retain.

From a functionality standpoint, this is very interesting, though. With the aforementioned death of WebCL, as well as the sluggish progress of WebGL Compute Shaders, there’s a lot of room to use one (or more) GPUs in a system for high-end compute tasks. Even if you are not interested in gaming on a web browser, although many people are, especially if you count the market that Adobe Flash dominated for the last ten years, you might want to GPU-accelerate photo and video tasks. Having an API that allows for this would be very helpful going forward, although, as stated, others are working on it, like The Khronos Group with WebGL compute shaders. On the other-other hand, an API that allows explicit multi-GPU would be even more interesting.

Further, it sounds like they’re even intending to ingest byte-code, like what DirectX 12 and Vulkan are doing with DXIL and SPIR-V, respectively, but it currently accepts shader code as a string and compiles it in the driver. This is interesting from a security standpoint, because it obfuscates what GPU-executed code consists of, but that’s up to the graphics and browser vendors to figure out... for now.

So when will we see it? No idea! There’s an experimental WebKit patch, which requires the Metal API, and an API proposal... a couple blog posts... a tweet or two... and that’s about it.

So what do you think? Does the API sound interesting? Does Apple’s involvement scare you? Or does getting scared about Apple’s involvement annoy you? Comment away! : D

Source: WebKit

NVIDIA Releases Vulkan Developer 376.80 Beta Drivers

Subject: Graphics Cards | February 3, 2017 - 05:58 PM |
Tagged: nvidia, graphics drivers, vulkan

On February 1st, NVIDIA released a new developer beta driver, which fixes a couple of issues with their Vulkan API implementation. Unlike what some sites have been reporting, you should not download it to play games that use the Vulkan API, like DOOM. In short, it is designed for developers, not end-users. The goal is to provide correct results when software interacts with the driver, not the best gaming performance or anything like that.

khronos-2016-vulkanlogo2.png

In a little more detail, it looks like 376.80 implements the Vulkan 1.0.39.1 SDK. This update addresses two issues with accessing devices and extensions, under certain conditions, when using the 1.0.39.0 SDK. 1.0.39.0 was released on January 23rd, and thus it will not even be a part of current video games. Even worse, it, like most graphics drivers for software developers, is based on the old, GeForce 376 branch, so it won’t even have NVIDIA’s most recent fixes and optimizations. NVIDIA does this so they can add or change the features that Vulkan developers require without needing to roll-in patches every time they make a "Game Ready" optimization or something. There is no reason to use this driver unless you are developing Vulkan applications, and you want to try out the new extensions. It will eventually make it to end users... when it's time.

If you are wishing to develop software using Vulkan’s bleeding-edge features, then check out NVIDIA’s developer portal to pick up the latest drivers. Basically everyone else should use 378.49 or its 378.57 hotfix.

Source: NVIDIA

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).