Support us on Patreon
PayPalToday is the release of the Vulkan API 1.3 specification update and The Khronos Group has put up a press release going over the changes. A vital API for the future of Linux gaming and the Steam Deck of course, with Steam Play Proton using Vulkan for the translation from Direct 3D for DXVK and VKD3D-Proton.
At a glance:
- 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 includes a number of extensions into the main core of Vulkan like dynamic rendering, an improved synchronization API and various other features. Khronos mentioned that no features added in 1.3 are optional to ensure consistency across the industry.
“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.
Vulkan continues to see industry-wide support from AMD, NVIDIA, Arm, Google and more companies.
On the driver side things are looking to be in pretty good shape. NVIDIA has release their new Vulkan Beta Driver version 470.62.22 which includes a "Fully conformant Vulkan 1.3 implementation". On the open source Mesa side there's merge requests up for Intel ANV and AMD RADV. NVIDIA also have their own blog post going over some details.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
11 comments
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
0 Likes
Are ray tracing features optional in general? I.e. they aren't part of any Vulkan version?
0 Likes
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.
0 Likes
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
Halo Infinite specifically uses DX12's dynamic rendering, which there is currently a draft to implement in dxvk
0 Likes
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.
If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.
Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?
Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.
If you know something about this I don't know, I'd be very keen to learn :)
0 Likes
And this is why people should think about names a bit more. I mean, how much stuff is there in any graphics thingie that has something to do with "rendering"? Stacks and stacks. And, how much is there relating to graphics that, you know, move, that's "dynamic"? More like, what isn't dynamic? So like, how many dozen things could you call "dynamic rendering" for what seemed like a good reason at the time?Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
Halo Infinite specifically uses DX12's dynamic rendering, which there is currently a draft to implement in dxvk
I think that refers to dynamic resolution rendering, which is not the same as Vulkan's dynamic rendering extension.
3 Likes, Who?
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.
If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.
Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?
Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.
If you know something about this I don't know, I'd be very keen to learn :)
Lighting (specifically deferred lighting) I mentioned because it's the one case I've found where a sub-pass has given good performance boosts: it's the same framebuffer size, and is a distinct pass (intervening geometry means you can't simply incorporate it into the colour/normal/depth pass). Deferred lighting of this fashion is falling out of favour because of newer techniques that handle transparency better though.
Anyway, performance improvements were seen even on desktop GPUs, which from a hardware perspective I believe use a kind of tile-based immediate mode these days (though to be honest I've not kept track with the latest desktop or mobile GPU architectures, which might have diverged again), and the driver can definitely take hints from the program to setup that nicely (even if just for caching). My limits of knowledge on the matter end there - I know the driver can optimise sub-passes even on desktop, but exactly what it does I've never bothered to look into detail at (and it'd change between hardware anyway).
All that being said, I'm also aware that many (myself included) don't like the render pass interface (it's a bit of a pain to setup) and I'm sure there are hints elsewhere that a driver can use (or that Khronos will introduce) just so that the benefits of sub-passes can be used (where applicable) without annoying the developer.
Interesting, my team (ANGLE) is dedicated to TBRs right now, and I never thought to measure on IMR, but I'm still a bit surprised you could measure anything noticeable. I guess I need an arch update too.
0 Likes
Hopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.
Not sure what one has to do with the other?
Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.
A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.
I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.
Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.
It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.
If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.
Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?
Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.
If you know something about this I don't know, I'd be very keen to learn :)
Lighting (specifically deferred lighting) I mentioned because it's the one case I've found where a sub-pass has given good performance boosts: it's the same framebuffer size, and is a distinct pass (intervening geometry means you can't simply incorporate it into the colour/normal/depth pass). Deferred lighting of this fashion is falling out of favour because of newer techniques that handle transparency better though.
Anyway, performance improvements were seen even on desktop GPUs, which from a hardware perspective I believe use a kind of tile-based immediate mode these days (though to be honest I've not kept track with the latest desktop or mobile GPU architectures, which might have diverged again), and the driver can definitely take hints from the program to setup that nicely (even if just for caching). My limits of knowledge on the matter end there - I know the driver can optimise sub-passes even on desktop, but exactly what it does I've never bothered to look into detail at (and it'd change between hardware anyway).
All that being said, I'm also aware that many (myself included) don't like the render pass interface (it's a bit of a pain to setup) and I'm sure there are hints elsewhere that a driver can use (or that Khronos will introduce) just so that the benefits of sub-passes can be used (where applicable) without annoying the developer.
Interesting, my team (ANGLE) is dedicated to TBRs right now, and I never thought to measure on IMR, but I'm still a bit surprised you could measure anything noticeable. I guess I need an arch update too.
You'll have to tell me if the new extensions make life easier at all, because I'm insatiably curious about such things!
Hah, it'll be years before we can use anything shiny on Android (at which point they are not shiny anymore). More importantly, no, it's known that dynamic rendering on TBR is actually less optimal than explicit subpasses. It may one day be better though.
That said, yes it would have made things easier if we didn't have framebuffer objects etc, though some existing extensions do alleviate the pain already (like imageless framebuffers)
0 Likes
https://lists.freedesktop.org/archives/mesa-dev/2022-February/225668.html
To be fair on links, I originally saw it here:
http://tuxmachines.org/node/161051
That's pretty quick to have mesa supporting Vulkan 1.3 (even if it's only RC1 at the time of writing).
Mesa is bigger than just some open source drivers for a niche OS. It's actually a solid codebase with a lot of eyes on it.
Show some respect
0 Likes
https://lists.freedesktop.org/archives/mesa-dev/2022-February/225668.html
To be fair on links, I originally saw it here:
http://tuxmachines.org/node/161051
That's pretty quick to have mesa supporting Vulkan 1.3 (even if it's only RC1 at the time of writing).
Mesa is bigger than just some open source drivers for a niche OS. It's actually a solid codebase with a lot of eyes on it.
Show some respect
uh.....what?
Not sure if I'm reading it in the tone intended....
Mesa has traditionally waited until some spec is released before implementing it, meaning (at least in the past) it had lagged behind such support. Being already in a position to support Vulkan 1.3 suggests even more of a changing landscape, where Mesa is on par with the proprietary driver releases and that important new features are being provided at the same time between proprietary and FOSS drivers (thanks to community involvement).
The "show some respect part" was obviously a joke, but my reply was serious and it actually applies as a reply to your new comment too. Mesa is a big thing now. It had 1.3 conformance submissions submitted before 1.3 was even announced FYI.
Much like Linux itself, it's not so much the "community" that's driving it anymore as it is various companies.
0 Likes
https://lists.freedesktop.org/archives/mesa-dev/2022-February/225668.html
To be fair on links, I originally saw it here:
http://tuxmachines.org/node/161051
That's pretty quick to have mesa supporting Vulkan 1.3 (even if it's only RC1 at the time of writing).
Mesa is bigger than just some open source drivers for a niche OS. It's actually a solid codebase with a lot of eyes on it.
Show some respect
uh.....what?
Not sure if I'm reading it in the tone intended....
Mesa has traditionally waited until some spec is released before implementing it, meaning (at least in the past) it had lagged behind such support. Being already in a position to support Vulkan 1.3 suggests even more of a changing landscape, where Mesa is on par with the proprietary driver releases and that important new features are being provided at the same time between proprietary and FOSS drivers (thanks to community involvement).
The "show some respect part" was obviously a joke, but my reply was serious and it actually applies as a reply to your new comment too. Mesa is a big thing now. It had 1.3 conformance submissions submitted before 1.3 was even announced FYI.
Much like Linux itself, it's not so much the "community" that's driving it anymore as it is various companies.
Quite aware of where most Mesa development comes from and just how far it's come, but it's still a collection of drivers, developed in full view of and with the community. Equally however, AMD can't dictate development direction for the entirety of Mesa, nor can Intel, or anyone else. Having possible Vulkan 1.3 support so early is a compliment of how well Mesa is doing now, not a criticism, with underlying implication of hope that this will continue in the future.
If I mention that and it's read in a negative way, then I most definitely need to walk away from even more of the community.
Uh no, of course it was obvious you were complementing mesa. And yes, they are awesome. Perhaps you misunderstood my original comment. What I meant was "of course mesa is awesome, how dare you be surprised" in a joking way.
Not sure how you thought I would read your comments as a criticism of mesa, lol
0 Likes
See more from me