Mark superseded VK_KHR_surface commands as legacy#2763
Conversation
14bc01b to
85ea25d
Compare
|
I'm guessing EXT should also be obsoleted by KHR, but that feels like something that should be done in a big "mark all EXTs that have KHR variants as legacy" PR? |
|
@cubanismo this is superficially an SI PR, but the underlying obsoletion issue can be brought up on the maintenance call. |
You mean vkGetPhysicalDeviceSurfaceCapabilities2EXT()? vkGetPhysicalDeviceSurfaceCapabilities2KHR() is not a promoted version of that function, and the EXT version exposes functionality the KHR does not, so it should not deprecate it. VK_KHR_get_surface_capabilities isn't a real extension name, so you should probably pick a different title for the commit/PR, but otherwise, I think this looks OK. |
|
2026-06-10 maintenance call: technically looks fine, but legacy/deprecation changes require main WG approval. Scheduled for next meeting. |
|
Fixed: Spelling error, PR/commit title |
It is not related. There's an error in a script in the repository that test comes from, and it is affecting all our CI runs until it's fixed. |
Similar logic to legacy-gpdp2, only for the VK_KHR_surface extension.
(I started off wanting to write a bpa check for it, but since the legacy checks are auto-generated from vk.xml, this seems the correct place)