Podcast #451 - New Surface Pro, Analog Keyboards, Water Cooled PSUs and more!

Subject: General Tech | May 25, 2017 - 11:12 AM |
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!

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, Jim Tanous, Ken Addison

Program length: 1:39:25

Podcast topics of discussion:

  1. Week in Review:
  2. Casper!
  3. News items of interest:
  4. Hardware/Software Picks of the Week
  5. Closing/outro

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

Manufacturer: The Khronos Group

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.

Subject: General Tech
Manufacturer: The Khronos Group

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.

Long-time readers of PC Perspective might remember that I was investigating GPU-accelerated software rendering in WebCL (via Nokia’s implementation). The thought was that I could concede the raster performance of modern GPUs and make up for it with added control, the ability to explicitly target secondary compute devices, and the ability to run in a web browser. This took place in 2013, before AMD announced Mantle and browser vendors expressed a clear disinterest in exposing OpenCL through JavaScript. Seeing the idea was about to be crushed, I pulled out the GPU-accelerated audio ideas into a more-focused project, but that part of my history is irrelevant to this post.

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.

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.


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.

GDC 2017: zSpace Joins OpenXR Working Group

Subject: General Tech | March 3, 2017 - 07:01 AM |
Tagged: zspace, VR, Khronos

About a year before I joined PC Perspective, I acquired a degree in Education, which involved teaching at a local high school. Even though that was just five years after graduating high school, the amount of available technology has exploded in that time. SmartBoards were relevant enough to be taught at my teacher’s college just in case you got one. Contrast this to when I was a high school student, where “overhead projector” was assumed to mean “transparent paper and erasable marker”.

Why do I mention this? Well, basically everyone in the tech industry has been investigating the potential of VR and AR for the last couple of years, and education is a very obvious and practical application of it.

In this case, zSpace reached out and informed that they just joined the Khronos Group’s OpenXR Working Group. They hope to guide the specification from the educational technology perspective. From what I can see on their website, their products are basically like Wacom Cintiqs, except that the pen can function the volume of air in front of the screen, and glasses with markers adjust the output image to make it look like objects are floating between you and the display.

If you’re in the education sector, then be sure to check out what zSpace is doing, if only to be aware of the teaching tools that are available in the world. Every teacher I knew enjoyed browsing Staples, looking through the various bits of stationary for ideas, like recipe cards for cheap, impromptu student polls and challenges.

As for the rest of us? The more mainstream VR and AR is, the more innovation will occur, especially when they contribute back to open standards; win win.

Source: zSpace

GDC 2017: The Khronos Group (re-)Announces OpenXR

Subject: General Tech | March 1, 2017 - 08:12 PM |
Tagged: VR, pc gaming, openxr, Khronos

While the Vulkan update headlines the Khronos Group’s presence at GDC 2017, they also re-announced their VR initiative, now called OpenXR. This specification wraps around the individual SDKs, outlining functionality that is to be exposed to the application and the devices. If a device implements the device layer, then it will immediately support everything that uses the standard, and vice-versa.


OpenVR was donated by Valve, leading to OpenXR...
... because an X is really just a reflected V, right?

Like OpenGL and Vulkan, individual vendors will still be allowed to implement their own functionality, which I’m hoping will be mostly exposed through extensions. The goal is to ensure that users can, at a minimum, enjoy the base experience of any title on any device.

They are aiming for 2018, but interested parties should contribute now to influence the initial release.

Linked Multi-GPU Arrives... for Developers

The Khronos Group has released the Vulkan 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.


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


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.

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.


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.

Podcast #428 - Khronos Group, Enterprise SSDs/HDDs, Water-cooled Cases, Mechwarrior

Subject: Editorial | December 8, 2016 - 04:00 PM |
Tagged: podcast, Thrustmaster, thermaltake, tablet, snapdragon, razer, nvidia, microsoft, Mechwarrior, Khronos, Intel, hp, evga, Deepcool, AUKEY

PC Perspective Podcast #428 - 12/8/16

Join us this week as we discuss Khronos Group, Enterprise SSDs, Water cooled cases  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, Josh Walrath, Jeremy Hellstrom

Program length: 1:13:35

  1. Join our spam list to get notified when we go live!
  2. Patreon
  3. Win a White Special Edition Corsair RM1000i Power Supply!
  4. Week in Review:
    1. 0:04:16 AUKEY KM-G3 RGB Mechanical Gaming Keyboard Review
    2. 0:08:06 Thrustmaster TMX Review: Budget FFB for Xbox One and PC
    3. 0:15:16 Deepcool GamerStorm GENOME Liquid-Cooled Case Review
    4. 0:23:06 EVGA SuperNOVA 550W G3 Power Supply Review
    5. 0:28:01 Qualcomm and Microsoft Bring Full Windows 10 to Snapdragon Devices
  5. News items of interest:
    1. 0:32:07 Razer Joins The Khronos Group
    2. 0:36:54 Thermaltake Launches Water Cooling Friendly E-ATX Tower 900 Series Case
    3. 0:39:32 Intel Z270 Express and H270 Express Chipsets Support Kaby Lake, More PCI-E 3.0 Lanes
    4. 0:42:12 MechWarrior 5: Mercenaries Announced on Unreal Engine 4
    5. 0:46:10 HP Launches Ruggedized Apollo Lake Powered Convertible Tablet For Students
    6. 0:47:33 Micron Launches 5100 Series Enterprise SSDs - 3D TLC up to 8TB!
    7. 0:52:12 WD and HGST Refresh Enterprise SSDs to Include 8TB, Push HDDs to 12TB and Beyond
    8. 1:02:37 NVIDIA Releases GeForce 376.19 Drivers (and Two Contests)
    9. 1:04:14 The Khronos Group Announces VR Standard Initiative
  6. Hardware/Software Picks of the Week
    1. Ryan: Uber, but boats  … CanUber
    2. Jeremy: PRUSA i3 MK2 printer Store link
    3. Josh: Hitting low cost per GB!
    4. Allyn: iRoller
  7. http://pcper.com/podcast
  8. http://twitter.com/ryanshrout and http://twitter.com/pcper
  9. Closing/outro

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

Subject: General Tech
Manufacturer: The Khronos Group

Maybe Good that Valve Called their API OpenVR?

Update, December 6th, 2016 @ 2:46pm EST: Khronos has updated the images on their website, and those changes are now implemented on our post. The flow-chart image changed dramatically, but the members image has also added LunarG.

Original Post Below

The Khronos Group has just announced their VR initiative, which is in the early, call for participation stage. The goal is to produce an API that can be targeted by drivers from each vendor, so that applications can write once and target all compatible devices. The current list of participants are: Epic Games, Google, Oculus VR, Razer, Valve, AMD, ARM, Intel, NVIDIA, VeriSilicon, Sensics, and Tobii. The point of this announcement is to get even more companies involved, before it matures.


Image Credit: The Khronos Group

Valve, in particular, has donated their OpenVR API to Khronos Group. I assume that this will provide the starting point for the initiative, similar to how AMD donated Mantle to found Vulkan, which overcomes the decision paralysis of a blank canvas. Also, especially for VR, I doubt these decisions would significantly affect individual implementations. If it does, though, now would be the time for them to propose edits.

In terms of time-frame, it’s early enough that the project scope hasn’t even been defined, so schedules can vary. They do claim that, based on past experiences, about 18 months is “often typical”.

That’s about it for the announcement; on to my analysis.


Image Credit: The Khronos Group, modified

First, it’s good that The Khronos Group are the ones taking this on. Not only do they have the weight to influence the industry, especially with most of these companies having already collaborated on other projects, like OpenGL, OpenCL, and Vulkan, but their standards tend to embrace extensions. This allows Oculus, Valve, and others to add special functionality that can be picked up by applications, but still be compatible at a base level with the rest of the ecosystem. To be clear, the announcement said nothing about extensions, but it would definitely make sense for VR, which can vary with interface methods, eye-tracking, player tracking, and so forth.

If extensions end up being a thing, this controlled competition allows the standard as a whole to evolve. If an extension ends up being popular, that guides development of multi-vendor extensions, which eventually may be absorbed into the core specification. On the other hand, The Khronos Group might decide that, for VR specifically, the core functionality is small and stable enough that extensions would be unnecessary. Who knows at this point.

Second, The Khronos Group stated that Razer joined for this initiative specifically. A few days ago, we posted news and assumed that they wanted to have input into an existing initiative, like Vulkan. While they still might, their main intentions are to contribute to this VR platform.

Third, there are a few interesting omissions from the list of companies.


Microsoft, who recently announced a VR ecosystem for Windows 10 (along with the possibly-applicable HoloLens of course), and is a member of the Khronos Group, isn’t part of the initiative, at least not yet. This makes sense from a historical standpoint, as Microsoft tends to assert control over APIs from the ground up. They are, or I should say were, fairly reluctant to collaborate, unless absolutely necessary. This has changed recently, starting with their participation with the W3C, because good God I hope web browsers conform to a standard, but also their recent membership with the Khronos Group, hiring ex-Mozilla employees, and so forth. Microsoft has been lauding how they embrace openness lately, but not in this way yet.

Speaking of Mozilla, that non-profit organization has been partnered with Google on WebVR for a few years now. While Google is a member of this announcement, it seems to be mostly based around their Daydream initiative. The lack of WebVR involvement with whatever API comes out of this initiative is a bit disappointing, but, again, it’s early days. I hope to see Mozilla and the web browser side of Google jump in and participate, especially if video game engines continue to experiment with cross-compiling to Web standards.

It's also surprising to not see Qualcomm's name on this list. The dominant mobile SoC vendor is a part of many Khronos-based groups including Vulkan, OpenCL, and others, so it's odd to have this omission here. It is early, so there isn't any reason to have concern over a split, but Qualcomm's strides into VR with development kits, platform advancements and other initiatives have picked up in recent months and I imagine it will have input on what this standard becomes.

And that’s all that I can think of at the moment. If you have any interests or concerns, be sure to drop a line in the comments. Registration is not required.