Proposed fix for the Vulkan no-op discard_texture

[edTheGuy00]

The Vulkan backend’s discard_texture is still a no-op on trunk (source, “TODO: Current implementation no-ops”). This is the issue described in #5723 and #2038.

Before opening a PR against trunk, I’d like to agree on how to handle it.

What goes wrong

When a SurfaceTexture is dropped without being presented, wgpu calls discard_texture. On Vulkan, that currently does nothing, so the image remains acquired until the swapchain is destroyed. Without an extension, the only way to return it is through vkQueuePresentKHR.

The spec only guarantees that vkAcquireNextImageKHR returns in finite time while the application holds at most S−M images, where S is the swapchain image count and M is minImageCount (forward-progress requirements).

On an Adreno device running Android/Vulkan, two discarded frames were enough to hit this with wgpu’s minImageCount. Every subsequent get_current_texture call timed out, and the app never presented another frame. DX12 recovers because discarding decrements acquired_count, allowing the next acquire to return the same back buffer.

Proposed fix

1. Keep the discarded image and return it on the next acquire.
   This is the approach suggested in wgpu_hal::Surface::discard_texture broken on Vulkan #5723. discard_texture would store the SurfaceTexture in the swapchain, and the next acquire would return it without calling vkAcquireNextImageKHR. It wouldn’t require any device extensions.

   The semaphore state should remain valid:

   • If no submission used the image, its acquire semaphore is still signaled. The next submission that draws to the image waits on it once, consuming the signal (semaphore waiting rules).
   • If a submission already used the image, the present semaphores it signaled still need to be waited on when the image is eventually presented.
     On reconfigure, release_resources would drop the retained image before destroying the semaphores. The swapchain destruction requirement is that all uses of the image have completed (VUID-01282).

2. Release the image directly where the maintenance extension is available.
   With VK_KHR_swapchain_maintenance1 or VK_EXT_swapchain_maintenance1 and the swapchainMaintenance1 feature enabled, discard could call vkReleaseSwapchainImagesKHR. The image must be idle before release (release requirements).

One detail to resolve is the acquire semaphore. The release reference page doesn’t say what happens to it, but vkAcquireNextImageKHR requires the semaphore to be unsignaled and have no pending operations before reuse (VUID-01286, VUID-01779). My plan is to consume the signal with an empty vkQueueSubmit that waits on the semaphore before reusing it.

Approach 1 would remain the fallback.

Testing so far

I have a prototype of approach 1 on top of v30.0.1. It fixes the hang on an Adreno device, including when the swapchain is recreated while an image is being retained. I’ll also run it with the Khronos validation layer before opening the PR.

Questions

1. Does approach 1 sound right, along the lines suggested in wgpu_hal::Surface::discard_texture broken on Vulkan #5723?
2. For approach 2, should we enable the extension whenever it’s available, or make it opt-in? Is an empty submit to consume the acquire semaphore acceptable, or would you prefer retiring and replacing the semaphore?
3. Should this PR also cover the panic path in release_inner, which currently skips the HAL discard, or should that be a separate change?