Allow chaining extension structs onto VkPresentInfoKHR at present time - #9847
Allow chaining extension structs onto VkPresentInfoKHR at present time#9847stuartparmenter wants to merge 4 commits into
Conversation
inner-daemons
left a comment
inner-daemons
left a comment
There was a problem hiding this comment.
I think that you mostly copied the support for vk_google_present_timing so some of my style comments might not need to be addressed (they are my opinion but go against previous project decisions).
I am incredibly skeptical of this though. Special integration with an nvidia-on-vulkan only extension is weird and I wouldn't like to add very many cases like this. I'd much prefer to let users plug in vulkan extensions as they need them. My last comment proposed a solution for this.
Either way I would not be in favor of this PR landing but other maintainers can opine on that, I've reviewed the code and it looks mostly fine.
Adds wgpu_hal::vulkan::Surface::set_next_present_chain(), which attaches a caller-provided pNext chain to the VkPresentInfoKHR of the surface's next presentation. Combined with Adapter::open_with_callback() for enabling the corresponding device extension, this allows using presentation extensions wgpu has no dedicated support for, such as VK_NV_present_metering.
a767e70 to
5430e2d
Compare
stuartparmenter
changed the title
VK_NV_present_metering support
|
Reworked as suggested — thanks for the pointer. What's left is a single generic |
Defines the extension's structs manually (not yet in ash) and enables the extension in request_device when supported, reported via FeatureSupport::present_metering_supported. PresentMetering owns the VkSetPresentConfigNV chained onto the next present via wgpu's new Surface::set_next_present_chain (gfx-rs/wgpu#9847), which meters the display timing of a batch of presented frames. Temporarily patches wgpu to a local checkout until a release includes set_next_present_chain.
New paced_present module (behind the paced_present cargo feature) lets a producer take over a window's swapchain presentation and present multiple textures per rendered frame, evenly metered by the driver via VK_NV_present_metering (wgpu VULKAN_NV_PRESENT_METERING, gfx-rs/wgpu#9847). Producers mark windows in PacedWindows during extract (suppressing normal swapchain acquisition) and submit a PacedPresentPlan of texture views; presentation blits each with the screenshot pipeline and presents back to back. Also adds a public ScreenshotPreparation system set so attachment overriding systems can order against screenshot preparation, and points [patch.crates-io] at the wgpu branch exposing the extension.
|
@cwfitzgerald Now that it is possible to handle it manually, should we remove the special support for vk_google_present_timing? |
inner-daemons
left a comment
inner-daemons
left a comment
There was a problem hiding this comment.
Honestly looks entirely good to me, minus a nit about the changelog.
|
|
||
| #### Vulkan | ||
|
|
||
| - Add `wgpu_hal::vulkan::Surface::set_next_present_chain`, which attaches a caller-provided `pNext` chain to the `VkPresentInfoKHR` of the surface's next presentation. With `Adapter::open_with_callback` to enable the device extension, this supports presentation extensions wgpu has no dedicated support for, such as [VK_NV_present_metering](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_present_metering.html) for metering the display timing of frame-generation frames. By @stuartparmenter in [#9847](https://github.com/gfx-rs/wgpu/pull/9847). |
There was a problem hiding this comment.
Normally we have a section for wgpu-hal which is separate from wgpu so that people who are using wgpu don't have to filter through e.g. a bunch of breaking changes on wgpu-hal that doesn't affect them.
4 participants
Connections
Reworked per review feedback (#9847 (review)): instead of dedicated
VK_NV_present_meteringsupport, this now adds a generic extension point.Description
Adds
wgpu_hal::vulkan::Surface::set_next_present_chain(), reachable viaSurface::as_hal(), which attaches a caller-providedpNextchain to theVkPresentInfoKHRof the surface's next presentation. The chain is caller-owned (so driver-written feedback fields can be read back after the present), consumed by the next present, and discarded if the surface is reconfigured first.Combined with the existing
Adapter::open_with_callback()for enabling device extensions, this lets users plug in presentation extensions wgpu has no dedicated support for — e.g. VK_NV_present_metering, which meters the display timing of a batch of presented frames for frame generation — without wgpu carrying per-vendor code. The NV struct definitions now live in the consumer (dlss_wgpu) rather than in wgpu.Testing
Used for DLSS Frame Generation presentation pacing in a Bevy branch on Windows (RTX 5090, driver 610.74): the extension is enabled via
open_with_callback, and a caller-ownedVkSetPresentConfigNVis chained onto the first present of each generated+real frame batch. The driver meters the batch with no CPU-side present timing, and validation layers are quiet.Squash or Rebase?
Squash.
Checklist
wgpumay be affected behaviorally.CHANGELOG.mdentries for the user-facing effects of this change are present.