Khronos Releases Vulkan 1.3 Graphics API Specifications

[Uskompuf]

Today, The Khronos Group, an open consortium of industry-leading companies creating advanced interoperability standards, announced the latest updates to Vulkan, the cross-platform 3D graphics API and its ecosystem. The Vulkan 1.3 specification was released today, incorporating and mandating proven, developer-requested extensions to make that functionality consistently available across all supported platforms.

The Vulkan Working Group is developing a public roadmap to provide guidance on when and where more advanced Vulkan functionality will be supported. The Vulkan Roadmap 2022 milestone for mid-to-high-end hardware defines features beyond Vulkan 1.3 that will be available starting this year. Vulkan profiles will be introduced, with tooling, in the February 2022 Vulkan 1.3 SDK to precisely specify, manage and use sets of API capabilities. Profiles will be used to communicate functionality requirements for roadmaps, markets, platforms, and hardware and software developers.





Vulkan 1.3 and Vulkan Roadmap

Vulkan 1.3 incorporates a number of carefully selected extensions requested by the developer community into a new core version of the specification. These include dynamic rendering, additional dynamic state, an improved synchronization API, and a range of other features (see the Vulkan 1.3 and Roadmap blog post for details). Crucially, unlike previous revisions, no features added to Vulkan 1.3 are optional, ensuring their consistent availability in all implementations of this new API version.

As with previous versions of the specification, Vulkan 1.3 is designed to be accelerated on OpenGL ES 3.1-class hardware, enabling the core API to be supported in a wide range of devices and markets. Many Vulkan devices support functionality beyond the core specifications through optional extensions which individual hardware vendors may choose to support—or not. The Vulkan Roadmap aims to consolidate the support for selected extensions to provide a common functionality baseline in key markets.

Vulkan Roadmap 2022 announced today is the first defined milestone in the Vulkan Roadmap. All Vulkan Working Group hardware vendors actively developing mid-to-high-end devices for smartphone, tablet, laptop, console, and desktop platforms are committed to supporting this milestone, starting with several shipping products in 2022. The milestone requires support for Vulkan 1.3 plus a number of extensions the Working Group considers essential for the target market, including descriptor indexing, fragment shader stores and atomics, subgroup support in fragment shaders, independent blending, sample shading, anisotropic filtering, YCbCr sampling, and scalar block layout for buffer resources. Roadmap 2022 also raises minimum values for many hardware limits, including max image and image array dimensions, max subgroup size, and various limits on how many resources can be accessed per shader stage. See the Vulkan 1.3 and Roadmap blog post for more details.

Vulkan Profiles

The new Vulkan profile mechanism enables the precise specification and management of sets of API capabilities. Each profile specifies a core version of Vulkan plus a set of required extensions, with supported limits, features, and formats. Profiles provide a way to precisely communicate functionality requirements and device capabilities between participants in the Vulkan ecosystem to streamline the development and deployment of portable applications.

Google has developed and released the Android Baseline 2021 Profile to advertise the set of features beyond Vulkan 1.0 that are supported by a large majority of active devices in the Android ecosystem, including devices that are out of support and do not regularly receive driver updates.

The Vulkan Roadmap 2022 Profile will encode the Vulkan roadmap's first milestone currently documented in the Vulkan 1.3 specification for release with the Vulkan SDK in mid-February.

Khronos tooling will enable developers to generate their own application-specific feature profiles, easily determine whether a device supports a given profile, and enable the features/extensions in a profile at application startup. A beta version of the tooling will be released in mid-February as part of the Vulkan 1.3 SDK, and will include a machine-readable file format for profile definitions, files defining the profiles released to date, a header-only library, and profile simulation support via the new VK_KHRONOS_LAYER_profiles layer.

Vulkan's Evolution

"In this new phase of Vulkan's evolution, the Vulkan Working Group is taking significant steps to reduce fragmentation across the ecosystem and increase Vulkan's value to the industry as a reliable cross-platform GPU API. We continue to expose new hardware features as extensions while improving the Vulkan API with new core versions that are portable to a wide range of devices. And now with the Vulkan Roadmap, we are committing to enhanced transparency and communication to forge industry consensus on baseline functionality Profiles that best serve Vulkan's key markets," said Tom Olson, Vulkan Working Group Chair and Distinguished Engineer at Arm.

The Vulkan Working Group welcomes feedback on GitHub about Vulkan 1.3 and the new approach to providing roadmap information. Developers are invited to register for a free Vulkanised Webinar on February 1, 2022 that will provide more detail on today's announcement, and are welcome to join the Vulkan 1.3 Discord channel.

Industry Support

"AMD is pleased to announce that we expect to support for both Vulkan 1.3 and the Vulkan Roadmap 2022 profile on all AMD Radeon RX Vega Series and AMD RDNA architecture-enabled graphics cards. AMD Radeon Software beta drivers are available for developers today, with support in the final drivers expected in the next few months. The Vulkan Working Group taking the initiative to standardize hardware features across devices is an important step towards providing consistent support for developers across key markets, and we believe this will ultimately translate to better developer and end-user experiences," said Andrej Zdravkovic, Senior Vice President, Software Development, AMD.

"The release of the Vulkan 1.3 Specification is a significant milestone. The latest iteration of the Khronos standard brings enhancements to improve the developer experience, including the introduction of Vulkan profiles, making it simpler for developers to understand platform capabilities and target a wider range of devices. Arm is committed to providing developers the tools and technologies to enable the next generation of compelling on-device experiences, and will support Vulkan 1.3 and the Roadmap 2022 profile on our Mali GPUs," said Geraint North, senior director, Ecosystems and Engineering, Client Line of Business, Arm.

"Vulkan 1.3 and the Roadmap 2022 milestone bring many welcomed quality of life improvements for developers, such as dynamic rendering which eliminates the need for render pass and framebuffer objects and provides a more streamlined approach for rendering. We look forward to making these improvements available on Stadia," said Hai Nguyen, senior staff technical solutions engineer for Google Stadia.

"Holochip develops light field and AR flight training and simulation technology for the U.S. military and is incorporating new display capabilities into existing NAVAIR training environments. The Vulkan 1.3 spec will enable wide adoption of next-gen display devices. The Vulkan 1.3 spec paves the way for military simulation environments to benefit from the technical advances in the commercial rendering market. These advances will lead to greater effectiveness and cost savings of training and improve the ability of warfighters to safely mitigate risks," said Robert Batchko, CEO of Holochip Corporation.

"Vulkan's ability to enable hardware platforms with vastly different form factors and power envelopes means that it is the key API for our highly scalable GPUs, which are used from wearables to mobile, automotive and data center and desktop. Vulkan 1.3's standardization of different profiles significantly enhances the API's applicability to such a diverse range of devices and use cases. Vulkan 1.3 is the work of the leaders in the GPU industry, coming together to enable the future of GPUs, and we are thrilled to be a part of that," said Ploutarchos Galatsopoulos, director of software product management, Imagination Technologies.

"LunarG is excited about the new Vulkan Profiles solution. Using this framework, developers can create portable applications that will run across large sets of hardware guaranteed to have the necessary supported features. The Vulkan Profiles API library and Vulkan Profiles Layer, which are delivered with the Vulkan SDK, will allow developers to define, use, and develop Vulkan profiles," said Karen Ghavam, CEO and engineering director, Christophe Riccio, senior engineer, LunarG Inc.

"As a long-time supporter of Vulkan, NVIDIA is providing immediate full functionality Vulkan 1.3 drivers that support the Roadmap 2022 milestone on both Windows 10 and 11, and Linux, including popular distributions such as Ubuntu, Kylin and RHEL. NVIDIA has also prepared conformant Vulkan 1.3 drivers for our Jetson embedded computing platform," said Dwight Diercks, senior vice president of software engineering, NVIDIA. "Our Nsight Graphics and Nsight Systems tools have been updated to support Vulkan 1.3, offering a robust environment with deep support for developers to build and optimize Vulkan games and applications."

View at TechPowerUp Main Site

 

[GoldenX]

Wait, why is Polaris not mentioned there?

 

[0x4452]

Quite different responses from the major vendors:

"AMD is pleased to announce that we expect to support for both Vulkan 1.3 and the Vulkan Roadmap 2022 profile"
"NVIDIA is providing immediate full functionality Vulkan 1.3 drivers that support the Roadmap 2022 milestone on both Windows 10 and 11, and Linux"

 

[Prima.Vera]

So OpenGL is dead?

 

[Readlight]

works worse on mubile and desktop

 

[b4psm4m]

Wait, why is Polaris not mentioned there?

Read on AMD subreddit that polaris is not supported/does not have the features necessary to support 1.3.

 

[z1n0x]

Quite different responses from the major vendors:

"AMD is pleased to announce that we expect to support for both Vulkan 1.3 and the Vulkan Roadmap 2022 profile"
"NVIDIA is providing immediate full functionality Vulkan 1.3 drivers that support the Roadmap 2022 milestone on both Windows 10 and 11, and Linux"

Considering AMD tends to performs better under Vulkan, speed of adoption ≠ quality of the implementation.

 

[GoldenX]

Read on AMD subreddit that polaris is not supported/does not have the features necessary to support 1.3.

1.3 is just officializing optional extensions...

 

[efikkan]

I'm not impressed so far. Khronos has really made a mess of the Vulkan specification.
Firstly there is the version numbering scheme, which really doesn't tell much about the API at all. They've continuously been adding optional features to 1.2.x, and then all of a sudden some of them become required and the version number is bumped to 1.3… Semantic versioning is the proper way to do an API.
Secondly there is the overall mess of the API, so many structures and functions to set it up, with extremely long names. (not Java level bad, but it's getting close.)
Then there is the nonsensical "Hungarian notation" which is so annoying to use.
And then there is the issue of profiles, which can be done bad or well. Let's at least hope they don't screw up that part like they did in OpenGL.

I'm also a bit skeptical about having one API to fit every device. At least with OpenGL there was a dedicated embedded version. I find it hard to believe it will be easy to make a flexible and efficient API across tiny devices to powerful desktop GPUs.

I'm hoping for a 2.0 that's a clean rewrite. (not likely)

Read on AMD subreddit that polaris is not supported/does not have the features necessary to support 1.3.

That sounds like a poor excuse. There are very few driver differences between the GCN iterations and even RDNA1, which was intended to make it easy for them to maintain driver support. I really hope it's just stuck in QA and coming soon, because otherwise it will be hurting Vulkan adoptation a lot. It's only a few months since I saw Polaris cards for sale, there is a lot of them in use.

Lack of proper API support across all recent GPUs have been the main disadvantage of Vulkan and OpenGL vs. DirectX, and as usual AMD is the latest. This actually makes it really hard for developers to target a single API to balance supported hardware and features without making many workarounds.

 

[GoldenX]

Lack of proper API support across all recent GPUs have been the main disadvantage of Vulkan and OpenGL vs. DirectX, and as usual AMD is the latest. This actually makes it really hard for developers to target a single API to balance supported hardware and features without making many workarounds.

To make it worse, Vulkan has so many critical extensions as optionals, that the core spec is only good enough to run basic Android games.

 

[R-T-B]

So OpenGL is dead?

Has been for most things for a bit, really. It's ok for low end games... but not much more.

 

[efikkan]

To make it worse, Vulkan has so many critical extensions as optionals, that the core spec is only good enough to run basic Android games.

Yes, and this makes it quite a headache to handle, and either do various compromises or multiple implementations. If it's bad enough, the developer may have to write alternatives to entire render passes. While there are multiple feature levels in DirectX too, and it's unavoidable to have some differences between GPU generations, this is far worse in Vulkan and OpenGL. So developers may have to do a lot of verification and testing to ensure it's working well across various hardware. It's no accident that I have a stack of old GPUs.

Has been for most things for a bit, really. It's ok for low end games... but not much more.

It had feature parity up until the launch of Vulkan, with lower latency and higher performance (except OpenGL >3.x on AMD hardware). There has been a mess with Intel only supporting the core profile and lagging with OpenGL 4.x support for a while, and AMD's lack of proper support, and the AMD Mesa driver's very lacking support. For developers this means to have to either fall back to the least common multiple or to add workarounds to different feature levels.

You may associate it with low-end games, but there is nothing low-end about it. This may be because OpenGL is dominating in the indie game space, so there are a lot of "low-end" OpenGL games out there, which is the result of OpenGL being by far the easiest to learn and work with.

As for OpenGL being dead or not. OpenGL with "AZDO" features (many of the features of 4.3-4.6) is approaching or matching Vulkan in overhead and performance. So for many developing rendering engines it may be smarter to update an existing OpenGL renderer vs. rewriting it in Vulkan if it's an existing project. For new projects though, Vulkan is probably the better choice even though it's much harder to work with.

 

[R-T-B]

It had feature parity up until the launch of Vulkan

I mean, kinda. It always sucked on AMD in most any form, but that wasn't really the APIs fault. Still, as you note, since the launch of Vulkan, it's been very much a "maintenance mode" project.

You may associate it with low-end games, but there is nothing low-end about it.

In modern API terms, it is decidedly low end. I worked on a project that had to support it recently. It's vertex overhead is awful vs even DX11. I only imagine it gets worse as you move towards DX12/Vulkan.

Of course, this was in the constraints of Unity 2019, and their OpenGL profile may be old.

The project was sponsored by NASA and game developer Squad, and was the KSP DART range challenge. Feel free to look it up. We are rather proud of the pretty asteroid moonlet surface.

 

[GoldenX]

Has been for most things for a bit, really. It's ok for low end games... but not much more.

I would say Vulkan still fails to reach feature parity with OpenGL, specially if you consider vendor specific stuff.

 

[R-T-B]

I would say Vulkan still fails to reach feature parity with OpenGL, specially if you consider vendor specific stuff.

I honestly can't think of one thing you can't do in Vulkan that you can do in OpenGL. I mean, people have basically written complete DX11/OpenGL wrapper stacks in Vulkan, and they actually perform well... it's pretty wild.

If you can name something I'm all ears though. I just didn't see it when I was doing limited work with the APIs.

 

[efikkan]

In modern API terms, it is decidedly low end. I worked on a project that had to support it recently. It's vertex overhead is awful vs even DX11. I only imagine it gets worse as you move towards DX12/Vulkan.

Of course, this was in the constraints of Unity 2019, and their OpenGL profile may be old.

You said an important thing there, Unity. If using the built-in renderer, then your results will depend more on the quality of the renderer than the API itself. Especially with universal game engines like Unity, Godot, etc. which is structured around logical game objects, makes for very inefficient rendering. And even with other game engines, whenever you see them supporting multiple APIs, it usually means they didn't write separate render engines, they probably did it through an abstraction layer where e.g. DirectX API calls are translated to "equivalent" OpenGL calls. The end result is a sub-optimal renderer with poor performance. Even though DirectX, OpenGL, Vulkan and embedded APIs largely expose the same features, they are implemented differently, so the only way to do a fair comparison is to write an optimal renderer for each respective API. For OpenGL this would mean using batching, bindless features etc., and then you will get vertex throughput far exceeding DirectX 11. Supporting APIs through abstraction layers is not going to give a fixed performance penalty either, it really depends on what is rendered and how, and can be quite severe. There are very few games doing separate render engines, if any it's probably some which uses GNM on PlayStation, NVN(?) on Nintendo, etc.

Engines like Unity do allow people to do their own renderer to some extent though, so there is at least some potential there. The built-in renderer has horrendous performance regardless of API. If performance is important, using a specialized render engine or writing your own are the two real options. While writing a rendering engine for a AAA game is a tremendous task, a project with a limited scope is quite doable, and should easily outperform the built-in renderer in engines like Unity.

Edit:
As to it getting worse with DirectX 12 / Vulkan, quite possible. There is at least a larger potential for developers to screw up

If you can name something I'm all ears though. I just didn't see it when I was doing limited work with the APIs.

If you want threads to work with multiple contexts to have one render while another loads assets, it can get quite messy in OpenGL.
Then there is ray tracing.

 

[GoldenX]

I honestly can't think of one thing you can't do in Vulkan that you can do in OpenGL. I mean, people have basically written complete DX11/OpenGL wrapper stacks in Vulkan, and they actually perform well... it's pretty wild.

If you can name something I'm all ears though. I just didn't see it when I was doing limited work with the APIs.

Well for once, I would like to ask Khronos to add VK_EXT_QUADS, for example.