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.
Subject: Editorial | December 8, 2016 - 09:00 PM | AlexL
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!
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: Allyn Malventano, Josh Walrath, Jeremy Hellstrom
Program length: 1:13:35
- Join our spam list to get notified when we go live!
- Win a White Special Edition Corsair RM1000i Power Supply!
- Week in Review:
- 0:04:16 AUKEY KM-G3 RGB Mechanical Gaming Keyboard Review
- 0:08:06 Thrustmaster TMX Review: Budget FFB for Xbox One and PC
- 0:15:16 Deepcool GamerStorm GENOME Liquid-Cooled Case Review
- 0:23:06 EVGA SuperNOVA 550W G3 Power Supply Review
- 0:28:01 Qualcomm and Microsoft Bring Full Windows 10 to Snapdragon Devices
- News items of interest:
- 0:32:07 Razer Joins The Khronos Group
- 0:36:54 Thermaltake Launches Water Cooling Friendly E-ATX Tower 900 Series Case
- 0:39:32 Intel Z270 Express and H270 Express Chipsets Support Kaby Lake, More PCI-E 3.0 Lanes
- 0:42:12 MechWarrior 5: Mercenaries Announced on Unreal Engine 4
- 0:46:10 HP Launches Ruggedized Apollo Lake Powered Convertible Tablet For Students
- 0:47:33 Micron Launches 5100 Series Enterprise SSDs - 3D TLC up to 8TB!
- 0:52:12 WD and HGST Refresh Enterprise SSDs to Include 8TB, Push HDDs to 12TB and Beyond
- 1:02:37 NVIDIA Releases GeForce 376.19 Drivers (and Two Contests)
- 1:04:14 The Khronos Group Announces VR Standard Initiative
- Hardware/Software Picks of the Week
- http://twitter.com/ryanshrout and http://twitter.com/pcper
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.
Subject: General Tech | December 2, 2016 - 05:58 AM | Scott Michaud
Tagged: VR, razer, osvr, Khronos
The Khronos Group is the standards body that maintains OpenGL, Vulkan, OpenCL, along with several other APIs and formats. They are made up of several members, which include companies of various sizes along with educational institutions, with a couple of tiers where members of the higher level, Promoter, get board nomination rights.
The lower level, Contributor, has just received a new member: Razer. The Khronos Group published a little statement to their front page, but didn’t provide a way to permanently link it and the Read More just directs to Razer’s homepage. Also, Razer didn’t provide a press release on their website, at least by the time this news was published, so I included the statement below to prevent it from getting buried in a few days:
The Khronos Group is proud to announce that Razer has joined as a Contributor Member. Razer is a world leader in connected devices and software for gamers. Its award-winning design and technology span systems, peripherals, audio and wearable technologies. Razer co-founded OSVR, an open-source platform that integrates VR, AR and mixed reality hardware and software APIs that support a universal VR ecosystem.
Based on this, it’s easy to speculate that Razer is looking to have a say and a vote in how graphics APIs evolve, nudging it as needed for OSVR, their co-founded virtual reality platform. Basically every other VR developer worth mentioning is already a member, including Google, Microsoft, Oculus VR, Samsung, Sony, and Valve. Likewise, Vulkan is undergoing rapid development, and the next version, codenamed Vulkan Next, has VR as one of its “top priorities”. It seems like a good time for Razer to get involved.
Otherwise? Not much to speak of here. Razer is a fairly big company that wants to be active in technology development, and it can easily afford the Khronos Group membership fee. I mean, the amount they spent on USB ports with a specific shade of green would cover about twenty years of membership to the Khronos Group, so it seems within their reach.
Subject: General Tech | February 18, 2016 - 07:16 PM | Ken Addison
Tagged: x16 LTE, vulkan, video, ssd, Samsung, qualcomm, podcast, pb328q, opengl, nvidia, micron, Khronos, gtx 950, asus, apple, 840 evo, 750ti, 750 evo, 3d nand
PC Perspective Podcast #387 - 02/18/2016
Join us this week as we discuss the ASUS PB328Q, Samsung 750 EVO SSD, the release of Vulkan and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the Store (audio only)
- RSS - Subscribe through your regular RSS reader (audio only)
- MP3 - Direct download link to the MP3 file
Hosts: Ryan Shrout, Jeremy Hellstrom, Josh Walrath, and Allyn Malventano
Program length: 1:34:18
Week in Review:
0:35:00 This episode of the PC Perspective Podcast is brought to you by Audible, the world's leading provider of audiobooks with more than 180,000 downloadable titles across all types of literature including fiction, nonfiction, and periodicals. For your free audiobook, go to audible.com/pcper
News items of interest:
1:07:00 This episode of PC Perspective Podcast is brought to you by Braintree. Even the best mobile app won’t work without the right payments API. That’s where the Braintree v.0 SDK comes in. One amazingly simple integration gives you every way to pay. Try out the sandbox and see for yourself at braintreepayments.com/pcper
Hardware/Software Picks of the Week
Caught Up to DirectX 12 in a Single Day
I'm not just talking about the specification. Members of the Khronos Group have also released compatible drivers, SDKs and tools to support them, conformance tests, and a proof-of-concept patch for Croteam's The Talos Principle. To reiterate, this is not a soft launch. The API, and its entire ecosystem, is out and ready for the public on Windows (at least 7+ at launch but a surprise Vista or XP announcement is technically possible) and several distributions of Linux. Google will provide an Android SDK in the near future.
I'm going to editorialize for the next two paragraphs. There was a concern that Vulkan would be too late. The thing is, as of today, Vulkan is now just as mature as DirectX 12. Of course, that could change at a moment's notice; we still don't know how the two APIs are being adopted behind the scenes. A few DirectX 12 titles are planned to launch in a few months, but no full, non-experimental, non-early access game currently exists. Each time I say this, someone links the Wikipedia list of DirectX 12 games. If you look at each entry, though, you'll see that all of them are either: early access, awaiting an unreleased DirectX 12 patch, or using a third-party engine (like Unreal Engine 4) that only list DirectX 12 as an experimental preview. No full, released, non-experimental DirectX 12 game exists today. Besides, if the latter counts, then you'll need to accept The Talos Principle's proof-of-concept patch, too.
But again, that could change. While today's launch speaks well to the Khronos Group and the API itself, it still needs to be adopted by third party engines, middleware, and software. These partners could, like the Khronos Group before today, be privately supporting Vulkan with the intent to flood out announcements; we won't know until they do... or don't. With the support of popular engines and frameworks, dependent software really just needs to enable it. This has not happened for DirectX 12 yet, and, now, there doesn't seem to be anything keeping it from happening for Vulkan at any moment. With the Game Developers Conference just a month away, we should soon find out.
But back to the announcement.
Vulkan-compatible drivers are launching today across multiple vendors and platforms, but I do not have a complete list. On Windows, I was told to expect drivers from NVIDIA for Windows 7, 8.x, 10 on Kepler and Maxwell GPUs. The standard is compatible with Fermi GPUs, but NVIDIA does not plan on supporting the API for those users due to its low market share. That said, they are paying attention to user feedback and they are not ruling it out, which probably means that they are keeping an open mind in case some piece of software gets popular and depends upon Vulkan. I have not heard from AMD or Intel about Vulkan drivers as of this writing, one way or the other. They could even arrive day one.
On Linux, NVIDIA, Intel, and Imagination Technologies have submitted conformant drivers.
Drivers alone do not make a hard launch, though. SDKs and tools have also arrived, including the LunarG SDK for Windows and Linux. LunarG is a company co-founded by Lens Owen, who had a previous graphics software company that was purchased by VMware. LunarG is backed by Valve, who also backed Vulkan in several other ways. The LunarG SDK helps developers validate their code, inspect what the API is doing, and otherwise debug. Even better, it is also open source, which means that the community can rapidly enhance it, even though it's in a releasable state as it is. RenderDoc,
the open-source graphics debugger by Crytek, will also add Vulkan support. ((Update (Feb 16 @ 12:39pm EST): Baldur Karlsson has just emailed me to let me know that it was a personal project at Crytek, not a Crytek project in general, and their GitHub page is much more up-to-date than the linked site.))
The major downside is that Vulkan (like Mantle and DX12) isn't simple.
These APIs are verbose and very different from previous ones, which requires more effort.
Image Credit: NVIDIA
There really isn't much to say about the Vulkan launch beyond this. What graphics APIs really try to accomplish is standardizing signals that enter and leave video cards, such that the GPUs know what to do with them. For the last two decades, we've settled on an arbitrary, single, global object that you attach buffers of data to, in specific formats, and call one of a half-dozen functions to send it.
Compute APIs, like CUDA and OpenCL, decided it was more efficient to handle queues, allowing the application to write commands and send them wherever they need to go. Multiple threads can write commands, and multiple accelerators (GPUs in our case) can be targeted individually. Vulkan, like Mantle and DirectX 12, takes this metaphor and adds graphics-specific instructions to it. Moreover, GPUs can schedule memory, compute, and graphics instructions at the same time, as long as the graphics task has leftover compute and memory resources, and / or the compute task has leftover memory resources.
This is not necessarily a “better” way to do graphics programming... it's different. That said, it has the potential to be much more efficient when dealing with lots of simple tasks that are sent from multiple CPU threads, especially to multiple GPUs (which currently require the driver to figure out how to convert draw calls into separate workloads -- leading to simplifications like mirrored memory and splitting workload by neighboring frames). Lots of tasks aligns well with video games, especially ones with lots of simple objects, like strategy games, shooters with lots of debris, or any game with large crowds of people. As it becomes ubiquitous, we'll see this bottleneck disappear and games will not need to be designed around these limitations. It might even be used for drawing with cross-platform 2D APIs, like Qt or even webpages, although those two examples (especially the Web) each have other, higher-priority bottlenecks. There are also other benefits to Vulkan.
The WebGL comparison is probably not as common knowledge as Khronos Group believes.
Still, Khronos Group was criticized when WebGL launched as "it was too tough for Web developers".
It didn't need to be easy. Frameworks arrived and simplified everything. It's now ubiquitous.
In fact, Adobe Animate CC (the successor to Flash Pro) is now a WebGL editor (experimentally).
Open platforms are required for this to become commonplace. Engines will probably target several APIs from their internal management APIs, but you can't target users who don't fit in any bucket. Vulkan brings this capability to basically any platform, as long as it has a compute-capable GPU and a driver developer who cares.
Thankfully, it arrived before any competitor established market share.
Subject: Graphics Cards | December 21, 2015 - 12:25 PM | Scott Michaud
Tagged: vulkan, Mantle, Khronos, dx12, DirectX 12
The Khronos Group announced on Friday that the Vulkan API will not ship until next year. The standards body was expecting to launch it at some point in 2015. In fact, when I was first briefed on it, they specifically said that 2015 was an “under-promise and over-deliver” estimate. Vulkan is an open graphics and compute standard that was derived from AMD's Mantle. It, like OpenCL 2.1, uses the SPIR-V language for compute and shading though, which can be compiled from subsets of a variety of languages.
I know that most people will be quick to blame The Khronos Group for this, because industry bodies moving slowly is a stereotype, but I don't think it applies. When AMD created Mantle, it bore some significant delays at all levels. Its drivers and software were held back, and the public release of its SDK was delayed out of existence. Again, it would be easy to blame AMD for this, but hold on. We now get to Microsoft. DirectX 12, which is maybe even closer to Mantle than Vulkan is due to its shading language, didn't roll out as aggressively as Microsoft expected, either. Software is still pretty much non-existent when they claimed, at GDC 2014, that about 50% of PC games would be DX12-compatible by Holiday 2015. We currently have... ... zero (excluding pre-release).
Say what you like about the three examples individually, but when all three show problems, then there might just be a few issues that took longer than expected to solve. Again, this is a completely different metaphor of translating voltages coming through a PCI Express bus into fancy graphics and GPU compute, and create all of the supporting ecosystems, too.
Speaking of ecosystems, The Khronos Group has also announced that Google has upgraded their membership to “Promoter” to get more involved with Vulkan development. Google has been sort-of hostile towards certain standards from The Khronos Group on Android in the past, such as disabling OpenCL on Nexus devices, and trying to steer developers into using Android Extension Pack and Renderscript. They seem to want to use Vulkan proper this time, which is always healthy for the API.
I guess look forward to Vulkan in 2016... hopefully early.
Subject: Graphics Cards | September 26, 2015 - 07:46 PM | Scott Michaud
Tagged: Nintendo, Khronos
Console developers need to use the APIs that are laid out by the system's creator. Nintendo has their own graphics API for the last three generations, called GX, although it is rumored to be somewhat like OpenGL. A few days ago, Nintendo's logo appeared on the Khronos Group's website as a Contributor Member. This leads sites like The Register to speculate that Nintendo “pledges allegiance to the Vulkan (API)”.
I wouldn't be so hasty.
There are many reasons why a company would want to become a member of the Khronos Group. Microsoft, for instance, decided that the small, $15,000 USD/year membership fee was worth it to influence the future of WebGL. Nintendo, at least currently, does not make their own web browser, they license NetFront from Access Co. Ltd., but that could change (just like their original choice of Opera Mini did). Even with a licensed browser, they might want to discuss and vote on the specifics. But yes, WebGL is unlikely to be on their minds, let alone a driving reason, especially since they are not involved with the W3C. Another unlikely option is OpenCL, especially if they get into cloud services, but I can't see them caring enough about the API to do anything more than blindly use it.
Vulkan is, in fact, most likely what Nintendo is interested in, but that also doesn't mean that they will support it. The membership fee is quite low for a company like Nintendo, and, even if they don't use the API, their input could benefit them, especially since they rely upon third parties for graphics processors. Pushing for additions to Vulkan could force GPU vendors to adopt it, so it will be available for their own APIs, and so forth. There might even be some learning, up to the limits of the Khronos Group's confidentiality requirements.
Or, of course, Nintendo could adopt the Vulkan API to some extent. We'll see. Either way, the gaming company is beginning to open up with industry bodies. This could be positive.
Subject: Graphics Cards, Processors, Mobile, Shows and Expos | August 10, 2015 - 01:01 PM | Scott Michaud
Tagged: vulkan, spir, siggraph 2015, Siggraph, opengl sc, OpenGL ES, opengl, opencl, Khronos
When the Khronos Group announced Vulkan at GDC, they mentioned that the API is coming this year, and that this date is intended to under promise and over deliver. Recently, fans were hoping that it would be published at SIGGRAPH, which officially begun yesterday. Unfortunately, Vulkan has not released. It does hold a significant chunk of the news, however. Also, it's not like DirectX 12 is holding a commanding lead at the moment. The headers were public only for a few months, and the code samples are less than two weeks old.
The organization made announcements for six products today: OpenGL, OpenGL ES, OpenGL SC, OpenCL, SPIR, and, as mentioned, Vulkan. They wanted to make their commitment clear, to all of their standards. Vulkan is urgent, but some developers will still want the framework of OpenGL. Bind what you need to the context, then issue a draw and, if you do it wrong, the driver will often clean up the mess for you anyway. The briefing was structure to be evident that it is still in their mind, which is likely why they made sure three OpenGL logos greeted me in their slide deck as early as possible. They are also taking and closely examining feedback about who wants to use Vulkan or OpenGL, and why.
As for Vulkan, confirmed platforms have been announced. Vendors have committed to drivers on Windows 7, 8, 10, Linux, including Steam OS, and Tizen (OSX and iOS are absent, though). Beyond all of that, Google will accept Vulkan on Android. This is a big deal, as Google, despite its open nature, has been avoiding several Khronos Group standards. For instance, Nexus phones and tablets do not have OpenCL drivers, although Google isn't stopping third parties from rolling it into their devices, like Samsung and NVIDIA. Direct support of Vulkan should help cross-platform development as well as, and more importantly, target the multi-core, relatively slow threaded processors of those devices. This could even be of significant use for web browsers, especially in sites with a lot of simple 2D effects. Google is also contributing support from their drawElements Quality Program (dEQP), which is a conformance test suite that they bought back in 2014. They are going to expand it to Vulkan, so that developers will have more consistency between devices -- a big win for Android.
While we're not done with Vulkan, one of the biggest announcements is OpenGL ES 3.2 and it fits here nicely. At around the time that OpenGL ES 3.1 brought Compute Shaders to the embedded platform, Google launched the Android Extension Pack (AEP). This absorbed OpenGL ES 3.1 and added Tessellation, Geometry Shaders, and ASTC texture compression to it. It was also more tension between Google and cross-platform developers, feeling like Google was trying to pull its developers away from Khronos Group. Today, OpenGL ES 3.2 was announced and includes each of the AEP features, plus a few more (like “enhanced” blending). Better yet, Google will support it directly.
Next up are the desktop standards, before we finish with a resurrected embedded standard.
OpenGL has a few new extensions added. One interesting one is the ability to assign locations to multi-samples within a pixel. There is a whole list of sub-pixel layouts, such as rotated grid and Poisson disc. Apparently this extension allows developers to choose it, as certain algorithms work better or worse for certain geometries and structures. There were probably vendor-specific extensions for a while, but now it's a ratified one. Another extension allows “streamlined sparse textures”, which helps manage data where the number of unpopulated entries outweighs the number of populated ones.
OpenCL 2.0 was given a refresh, too. It contains a few bug fixes and clarifications that will help it be adopted. C++ headers were also released, although I cannot comment much on it. I do not know the state that OpenCL 2.0 was in before now.
And this is when we make our way back to Vulkan.
SPIR-V, the code that runs on the GPU (or other offloading device, including the other cores of a CPU) in OpenCL and Vulkan is seeing a lot of community support. Projects are under way to allow developers to write GPU code in several interesting languages: Python, .NET (C#), Rust, Haskell, and many more. The slide lists nine that Khronos Group knows about, but those four are pretty interesting. Again, this is saying that you can write code in the aforementioned languages and have it run directly on a GPU. Curiously missing is HLSL, and the President of Khronos Group agreed that it would be a useful language. The ability to cross-compile HLSL into SPIR-V means that shader code written for DirectX 9, 10, 11, and 12 could be compiled for Vulkan. He expects that it won't take long for a project to start, and might already be happening somewhere outside his Google abilities. Regardless, those who are afraid to program in the C-like GLSL and HLSL shading languages might find C# and Python to be a bit more their speed, and they seem to be happening through SPIR-V.
As mentioned, we'll end on something completely different.
For several years, the OpenGL SC has been on hiatus. This group defines standards for graphics (and soon GPU compute) in “safety critical” applications. For the longest time, this meant aircraft. The dozens of planes (which I assume meant dozens of models of planes) that adopted this technology were fine with a fixed-function pipeline. It has been about ten years since OpenGL SC 1.0 launched, which was based on OpenGL ES 1.0. SC 2.0 is planned to launch in 2016, which will be based on the much more modern OpenGL ES 2 and ES 3 APIs that allow pixel and vertex shaders. The Khronos Group is asking for participation to direct SC 2.0, as well as a future graphics and compute API that is potentially based on Vulkan.
The devices that this platform intends to target are: aircraft (again), automobiles, drones, and robots. There are a lot of ways that GPUs can help these devices, but they need a good API to certify against. It needs to withstand more than an Ouya, because crashes could be much more literal.
Subject: General Tech, Graphics Cards | April 20, 2015 - 11:30 AM | Scott Michaud
Tagged: Red Hat, Khronos
With a brief blog post, Red Hat has announced that they are now members of the Khronos Group. Red Hat, one of the largest vendors of Linux software and services, would like to influence the direction of OpenGL and the upcoming Vulkan API. Also, apart from Valve, they are one of the only Linux vendors that contributes to the Khronos Group as an organization. I hope that their input counter-balances Apple, Google, and Microsoft, who are each members, in areas that are beneficial to the open-source operating system.
As for now, Red Hat intends to use their membership to propose OpenGL extensions as well as influence Vulkan as previously mentioned. It also seems reasonable that they would push for extensions to Vulkan, which the Khronos Group mentioned would support extensions at GDC, especially if something that they need fails to reach “core” status. While this feels late, I am glad that they at least joined now.