hal: cargo feature to allow using VK_GOOGLE_display_timing unsafely

[DJMcNab]

Connections

• https://raphlinus.github.io/ui/graphics/gpu/2021/10/22/swapchain-frame-pacing.html
• #gpu > Latency Investigation on the Linebender Zulip.
• Extended Presentation API Investigation #2869

Description
In many applications, you need to do frame pacing properly to get acceptable latency performance.
On Android, this is exposed through the VK_GOOGLE_display_timing device extension. However, for applications using wgpu, it is currently impossible to use this extension for three reasons, each of which are addressed in this PR:

1. It is impossible to access the raw vulkan swapchain object (e.g. to call vkGetPastPresentationTimingGOOGLE
2. It is impossible to create a device with this extension enabled.
3. It is impossible to extend the present call with the VkPresentTimesInfoGOOGLE

The solution here addresses the first of these by adding a raw_swapchain method to wgpu_hal::vulkan::Surface.
The remaining two are addressed using targeted hacks, both protected by the new perma-unstable wgpu-hal feature unstable_vulkan_google_display_timing. The extension is always enabled if available when the feature is set, and the additional present information for the "next" presentation is cached on the wgpu-hal::vulkan::Surface object, which will be accessed using wgpu::Surface::as_hal.

This PR does not change the high-level wgpu API, and instead requires users of this feature to add a dependency on wgpu-hal themselves.

Testing
This feature is currently not tested. My intention is to integrate this PR with Vello before this is merged.

I don't think it is possible to automate testing of this PR, as we do not have any tests running on Android, and only MoltenVK implements this outside of Android.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown N/A
  • --target wasm32-unknown-emscripten N/A
• Run cargo xtask test to run tests. These kill my editor and any terminal emulator at the moment, but I can't imagine this changes anything.
• Add change to CHANGELOG.md. See simple instructions inside file.

[cwfitzgerald]

I think we can activate the feature differently, but the code itself is fine.

[MarijnS95]

This looks interesting as a start but I wonder how useful it is without also providing the results from vkGetPastPresentationTimingGOOGLE(). Or are you driving these timings from Choreographer callbacks?

[DJMcNab]

This looks interesting as a start but I wonder how useful it is without also providing the results from vkGetPastPresentationTimingGOOGLE(). Or are you driving these timings from Choreographer callbacks?

I have documented this in the PR on the feature now - is it clearer. Essentially, because this isn't a fully supported feature, I expect users to manually set these things up themselves (i.e. call ash::google::display_timing::Device::new(), and handle the methods that way).

With the aim of keeping this change as focused as possible, I only provided the absolute bare minimum of functionality to allow experimenting with this extension outside of wgpu - i.e. the functionality which could not be accessed from the outside.

[DJMcNab]

I'm experimenting with this in my android-pacing branch, and indeed have it working as expected on Android DJMcNab/vello@2673d0c

[cwfitzgerald]

Nice, thanks!