`RawVulkanInitSettings` has difficulty handling common Vulkan patterns
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
We added support for custom Vulkan instance/device intiailization in #20565. However, it struggles to express some common Vulkan patterns.
Consider the following:
```rust
pub struct VulkanPlugin;
impl Plugin for VulkanPlugin {
fn build(&self, app: &mut App) {
let mut raw_vulkan_settings = app
.world_mut()
.get_resource_or_init::();
unsafe {
raw_vulkan_settings.add_create_device_callback(
move |mut args, adapter, additional_vulkan_features| {
let mut vk_sync_2_feature =
vk::PhysicalDeviceSynchronization2Features::default().synchronization2(true);
*args.create_info = args.create_info
.push_next(&mut vk_sync_2_feature);
});
}
}
}
```
We want to push `vk_sync_2_feature` onto the pNext chain of `create_info`. However, because we are adding a callback, this requires that `vk_sync_2_feature` lives longer than callback.
In the regular `open_with_callback` flow used by `wgpu`, this is trivially avoided as the callback is immediately invoked in the course of returning the device.
Contributor guide
Research direction
Start by reviewing the RawVulkanInitSettings and add_create_device_callback API introduced in #20565, then trace how the callback is stored and invoked during device creation. Compare this with wgpu's open_with_callback flow and identify how common pNext-chain setup can be represented without the current lifetime obstacle. Done means the documented Vulkan pattern is expressible and covered by relevant tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100