Skip to content

Conversation

Firestar99
Copy link
Member

@Firestar99 Firestar99 commented Sep 30, 2025

Followup from #418

I've noticed that running the ash runner with debug layers enabled (--debug-layers) prints tons of validation errors, all of which should be considered programming errors and sort of equivalent to a runtime panic. Instead of trying to fix what is there, I decided to completely rewrite the ash runner instead, and update it to the modern Vulkan 1.3 way you'd render things.

  • use Vulkan 1.3
  • use DynamicRendering feature replacing Framebuffers
  • extract MyDevice struct containing vk initialization
  • decouple rendering from swapchain management
  • redo swapchain sync, fixes validation errors, intentionally kept basic
  • make rendering lazily recreate its pipeline

MacOS: removes the ash-molten dependency, which means we now require MoltenVK (or the Vulkan SDK) to be installed on MacOS for the ash runner to work. The wgpu runner still works as normal, with the metal backend.

Reviews

Please test this on your machine with validation layers turned on, if possible (requires the Vulkan SDK). Report back if it runs and on which OS and graphics card.

git checkout simplify-ash-runner2
cargo run --bin example-runner-ash -- --debug-layer --shader=sky
cargo run --bin example-runner-ash -- --debug-layer --shader=mouse

Note:

  • --shader=sky: holding arrow keys should change brightness
  • --shader=mouse: should be animated
  • --debug-layer requires vulkan sdk

_ => {}
},
_ => event_loop_window_target.set_control_flow(ControlFlow::Wait),
_ => event_loop_window_target.set_control_flow(ControlFlow::Poll),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, is this the change that makes it animate continually instead of only while activating the mouse/keyboard?

..Default::default()
},
vk::PipelineShaderStageCreateInfo {
module: shader_module,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, you can use shader_module for multiple stages; the differing entry points distinguish them. 👍

.get_physical_device_surface_present_modes(self.pdevice, self.surface)
.unwrap()
pub fn create_swapchain(&self) -> anyhow::Result<(vk::SwapchainKHR, vk::Extent2D)> {
unsafe {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you keep the unsafe scope where it was originally? It's generally good for these scopes to be as small as possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was confused at first where this function is supposed to be. Turns out, in the rewrite commit this function got split, which moved the unsafe part into MySwapchainManager::recreate_swapchain and the property discovery part into MySwapchainManager::new.

Generally, I agree that the unsafe parts should be as short as possible. However, I do count setting up the properties to call the unsafe vulkan function towards the unsafe part, since wrong configuration is where most of the unsafety comes from.

@nnethercote
Copy link
Contributor

Thanks for cleaning this up, I don't understand everything about this code but the parts I do understand look good. I can see you've generally improved the error handling, fixed a bunch of "FIXME" comments, etc.

It would be nice to have some commit messages that are more than a single line. The "ash runner: rewrite" commit in particular changes a lot of code with zero explanation.

* use Vulkan 1.3
* use DynamicRendering feature replacing Framebuffers
* extract `MyDevice` struct containing vk initialization
* decouple rendering from swapchain management
* redo swapchain sync, fixes validation errors, intentionally kept basic
* make rendering lazily recreate its pipeline
@Firestar99 Firestar99 force-pushed the simplify-ash-runner2 branch from 6597b17 to 3007d25 Compare October 1, 2025 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants