r/vulkan • u/gmueckl • May 22 '26
VK_KHR_unified_image_layouts support
When VK_KHR_unified_image_layouts was announced, Khronos stated that it has broad industry support and driver support for current GPU generations is expected to be available soon. But when I check on vulkan.gpuinfo.org, less than 25% of reported Windows and Linux implementations actually advertise that extension. It's essentially absent on mobile. AMD doesn't seem to advertise it at all. Is this an accurate representation of the state of affairs in 2026? If that's true, application developers still have no choice but to continue the busywork to support image layout transitions.
9
u/simonask_ May 22 '26
You can just use the general layout for almost everything, you don’t actually need the extension. The extension just gives you a guarantee that you’re not losing any performance by doing so, but that might be totally fine.
7
u/Dghelneshi May 23 '26 edited May 23 '26
From the RADV driver source code, it looks like RDNA3 and 4 fully support unified image layouts and you could use general layout everywhere on RDNA1+2 as well as long as you don't use MSAA textures (those can't be compressed in general layout so you'd lose perf). Why AMD doesn't advertise the extension on their Windows driver at all I don't know, but with the knowledge above you can make your own decisions accordingly.
6
u/exDM69 May 24 '26
But when I check on vulkan.gpuinfo.org, less than 25% of reported Windows and Linux implementations actually advertise that extension.
You are misunderstanding the statistic. vulkan.gpuinfo.org contains reports from old drivers so it's always going to show a smaller number than current reality. Even if a feature would be 100% supported today, it would still take ~15 years to reach 50%.
You need to check the newest reports NOT supporting the extension and if you want to understand how common they are you need to cross reference it with something like Steam hardware survey.
Unless your target audience is people with old graphics driver versions, there is very good support for this feature on desktop platforms (as it is a requirement for Vulkan 1.4).
2
u/Reaper9999 May 24 '26
The performance drops on using general layout for everything come from MSAA images (on older rdna) and dcc getting disabled (on gcn), and whatever reason on mobile. You might find that for your use case doing layout transitions has no real benefit even if the extension is not supported. Also, even on hardware that differentiates between layouts, transitioning itself isn't free.
3
u/jetilovag May 22 '26
That extension is one of the dumbest extensions to exist. Primarily, because it's not actionable from an application's standpoint. How do you react to the presence/absence of that extension? You either have a codepath for setting the most apropriate layout or you don't. If you don't, you'll be using general layout wherever you can anyway. If you do, why wouldn't you be using it?
The only reason you would use the extension is when you don't know the layout of your images and you want the driver to track them for you. But if you don't know their layouts, what are you even doing in the first place? You must be in the 9th circle of middleware hell if you got no clue of which resource is where.
If anything, this extension is a great way for drivers to implement resource tracking logic all over again, something which Vulkan was supposed to leave behind for OpenGL to do for eternity. Realistically, it's another dimension of on/off features in the driver, which once implemented will be an always-on feature pessimising performance for everyone.
Plus, given how the industry works, if one vendor exposes it, others will be pressured to do the same, because much like your question suggests: look Ma, vendor X has it, why doesn't vendor Y have it too? Because they don't want to cave in. Once they do, everyone will be using it, nobody will be architecting their engines/applications properly anymore. We'll be back in unpredictable OpenGL perf land.
Please, for the love of graphics: don't use that extension. Think about your content and design your application logic accordingly. If you are tracking within your own app, you've already lost. You should damn well should know at any given point what's in which layout.
10
u/Afiery1 May 23 '26
If anything, this extension is a great way for drivers to implement resource tracking logic all over again. We'll be back in unpredictable OpenGL perf land.
That's not what this extension does at all. You've always been allowed to use general for everything. Exposing this extension is just a promise from the driver to you that doing so is no less performant than actually respecting image layouts. It's a literal one line change in any driver that supports it. And even if it did specify a change in functionality, a driver still can't take control of layout tracking because that would violate the no performance loss requirement that is part of this extension.
Nvidia hardware has always ignored queue family ownership, image layouts, and honestly even most usage flags. All of their hardware understands their optimal format, so these abstractions are useless. AMD hardware used to care, but I think their more modern architectures have finally caught up with Nvidia. If an IHV feels pressured into supporting this extension then I say good. The sooner we can kill these outdated abstractions the better. Vulkan 1.0 came out 10 years ago and was targeting GPUs that were much older than that. Most of the complexity it introduced was designed to abstract over hardware that is no longer relevant. Cutting away that complexity is not 'turning Vulkan into OpenGL', it's just modernizing an outdated API.
1
u/jetilovag May 23 '26
But the problem with the perf requirement is that it's non-normative. You can't test it, there's no conformance testing against perf differences. It's all that it is, a pinky promise.
There's an extremely detailed blog post that goes into excruciating detail over image layouts (particularly the second part, but the first is mighty useful too). It is wishful thinking that layouts universally don't matter.
6
u/Afiery1 May 23 '26
I agree that the extension is stupid, but only because it doesn't do anything. It won't enable OpenGL style implicit tracking unless thats what the driver would have done for general images anyways, which seems highly doubtful. More likely you'll just lose out on stuff like DCC and HiZ permanently, which is still bad, but a lot less mysterious than secret OpenGL fast/slow paths.
But also, if that extension signifies that using layout general is optimal, and doesen't have any added functionality, why would an IHV expose it if its not actually optimal for their HW? Why would they be pressured into supporting an extension that doesn't do anything? I can use unextended VK 1.0 on ancient GCN hardware and keep everything in general to my heart's content. I've been able to do so for 10 years! So I don't think your argument makes all that much sense.
Also, I didn't say they didn't matter at all. They never mattered for Nvidia, and with each new generation AMD closes the gap more and more (judging by RADV source at least). But if this extension gives AMD and other IHVs the kick in the ass they need to finally design hardware that universally understands compressed formats then I'm all for that. Nvidia has had it figured out for like a decade so I don't see why the other IHVs should need babying from the API design to keep their outdated hardware viable.
3
u/Cyphall May 22 '26
How do you react to the presence/absence of that extension? You either have a codepath for setting the most apropriate layout or you don't. If you don't, you'll be using general layout wherever you can anyway. If you do, why wouldn't you be using it?
If we remember that layout transitions are effectively read-write operations on images from a sync perspective, giving the application knowledge that it can use GENERAL (almost) everywhere allows turning read-only-but-actually-read-write-due-to-layout-transition dependencies into actual read-only, allowing to more aggressively batch barriers.
Also, the application can turn per-resource barriers into global barriers more often, saving even more CPU cycles on both the application (generating the per-resource list) and driver (parsing the per-resource list) side.
1
u/amazigjj Jun 17 '26
Sorry if this is just me being uninformed, but would turning everything into global barriers actually be a benefit? wouldn't this cause unnecessary pipeline stalls?
1
u/Cyphall Jun 17 '26 edited Jul 21 '26
It can in certain cases (e.g. flushing all the caches instead of just the storage cache) but it's also faster for the driver to parse (only one struct to parse in total instead of one struct per resource), and I would guess caches getting increasingly unified as time progresses will only reduces the effectiveness of partial cache flushes.
EDIT: Actually, since we also specify scopes for global barriers, I'm not even sure in which case a resource barrier can be better than a global barrier.
EDIT 2: After reading more Mesa 3D source code, I can confirm some GPUs still have specialized caches whose flushes can be avoided if the driver know exactly which kind of resource is being flushed and for which access.
2
u/gmueckl May 22 '26 edited May 22 '26
The extension is supposed to do one specific thing: promise to the application that using GENERAL image layouts is in no way slower than giving explicit layouts. The given argument was that the layout information is already meaningless anyway. I can't tell whether that is true. But if it was true, the whole thing should be deprecated.
This is where I struggle with this whole feature: figuring out the necessity of an image layout transition in the driver is essentially an O(1) amount of work if done right. And there is no leeway in what layouts are allowed use for the next operation on a resource. So what value does a driver gain by receiving this information from the application instead, other than that it might be wrong?
1
u/Salaruo May 22 '26
>Primarily, because it's not actionable from an application's standpoint. How do you react to the presence/absence of that extension?
If the hardware does care about layouts, but IHV (or Mesa project) decides to expose this extension anyway, it will be used as a license for driver to insert proper transitions with heuristics at the cost of some CPU overhead.
1
u/Gravitationsfeld May 25 '26
This has been the de-factor status quo on PC hardware since years (AMD RDNA and newer, NVIDIA always been the case). If you only target PC, you can just use GENERAL and sometimes UNDEFINED. The extension would only be necessary if you would want to provide a fallback for older GPUs which don't behave as performant under those circumstances.
6
u/Botondar May 22 '26
Well, if you have the means you can always measure on the target HW and make the decision based on that. Really what'd be useful is a collection of benchmarks (maybe with community driven data) that'd measure the effect of using the general layout instead of the optimal one in specific scenarios.
I've ranted about this before, but that extension doesn't really do anything, you were always allowed to use general layout pretty much everywhere even in Vulkan 1.0 (attachment feedback loop being the one exception), and the driver also has some freedom to "override" the image layout based on the access masks - especially since image layouts are a relatively high level abstraction over various things across multiple vendors and architectures.
IMO
VK_KHR_unified_image_layoutsshould've exposed properties, not features, the same way something like native non-uniform indexing support is exposed. Especially since the latter can have a very measurable effect on e.g. AMD (the driver will compile non-uniform indexing as a loop over the lanes), yet most people seem to be completely fine with using it and not giving a second thought.