Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the new swap chain model of gfx-hal #331

Merged
merged 6 commits into from
Nov 21, 2019
Merged

Conversation

zakorgy
Copy link

@zakorgy zakorgy commented Nov 7, 2019

This change is Reviewable

Copy link

@kvark kvark left a comment

Choose a reason for hiding this comment

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

Great changes! Just a few concerns raised

@@ -847,9 +868,6 @@ impl<B: hal::Backend> Device<B> {
self.device.wait_idle().unwrap();

let ref mut heaps = *self.heaps.lock().unwrap();
for frame in self.frames.drain(..) {
Copy link

Choose a reason for hiding this comment

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

we still want to drain this, I think

let (swap_chain, images) =
unsafe { device.create_swapchain(surface, swap_config, old_swap_chain) }
.expect("create_swapchain failed");
println!("## Image count {}", frame_count);
Copy link

Choose a reason for hiding this comment

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

debug print?

frame_depths.push(depth);
for _ in 1 .. frame_count {
frame_depths.push(
DepthBuffer::new(
Copy link

Choose a reason for hiding this comment

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

why are we creating N depth buffers? we should be able to use the same depth buffer for all frames
moreover, with picture caching we may not even need any depth buffers for the swapchain images

Copy link
Author

Choose a reason for hiding this comment

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

As I've found picture caching uses the depth buffer.


info!("Frames: {:?}", frames);
println!("## Frame depth count {:?}", frame_depths.len());
Copy link

Choose a reason for hiding this comment

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

debug print

@@ -2208,11 +2250,13 @@ impl<B: hal::Backend> Device<B> {
let img = &self.images[&fbo.texture_id];
(img.format, &img.core, fbo.layer_index)
} else {
(
println!("## This path is unimplemented!");
Copy link

Choose a reason for hiding this comment

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

warn or error?

self.viewport.rect,
&self.render_passes,
);
let old_frame = mem::replace(&mut self.frame, new_frame);
Copy link

Choose a reason for hiding this comment

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

should we just do self.frame.surface_image = Some(surface_image)) instead of creating a new one and doing the mem::replace?

unsafe {
match self.swap_chain.as_mut() {
Some(swap_chain) => {
let present_pass = self.render_passes.present_pass();
Copy link

Choose a reason for hiding this comment

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

why are we doing this pass? it seems empty

Copy link
Author

Choose a reason for hiding this comment

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

This is just a workaround to fix validation layer errors (that the frame image is not in a presentable layout) until I write the code which identifies the last render pass related to the frame image and we can start this pass there.

}
}

fn deinit(self, device: &B::Device) {
unsafe {
device.destroy_framebuffer(self.framebuffer);
Copy link

Choose a reason for hiding this comment

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

We need to be destroying the associated frame buffer right after it was presented.
See the quad example for the reference. If keep it, we are forcing Metal to have more than one CAMetalDrawable in flight.
Currently, the code appears to be destroying the framebuffer only after the next acquisition is done.

};

let surface_image = unsafe {
match surface.acquire_image(!0) {
Copy link

Choose a reason for hiding this comment

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

why are we acquiring an image in more than one place in the code?

match self.swap_chain.as_mut() {
Some(swap_chain) => {
let present_pass = self.render_passes.present_pass(self.frame_depth.is_some());
self.command_buffer.begin_render_pass(
Copy link

Choose a reason for hiding this comment

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

we definitely not want to have this pass :)

@zakorgy zakorgy force-pushed the new-swapchain branch 2 times, most recently from fc834a3 to 967e69e Compare November 15, 2019 15:19
@zakorgy
Copy link
Author

zakorgy commented Nov 15, 2019

A quick update on this PR: it's is in a state where everything works without validation layer errors with Vulkan backend. But I still need to nail down the number of render passes we use for the main target.
Changes since the last update:

  • Enabled read pixels functionality again
  • Enabled headless mode again
  • Added a shader to blit to the main target.
  • Finally fixed the validation layer errors during resize ( Check the validation layer #80 (comment) ): turned out the issue was that we handled the window dimensions and the viewport within the same variable.

@zakorgy zakorgy changed the title WIP Use the new swap chain model of gfx-hal Use the new swap chain model of gfx-hal Nov 18, 2019
@zakorgy zakorgy force-pushed the new-swapchain branch 2 times, most recently from 0fca15c to b236dcd Compare November 19, 2019 09:01
@zakorgy zakorgy requested a review from kvark November 19, 2019 12:51
Copy link

@kvark kvark left a comment

Choose a reason for hiding this comment

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

Looks like my requested changes are either applied or on track. Please proceed when ready!
Also, amazing work ❤️

@zakorgy zakorgy force-pushed the new-swapchain branch 2 times, most recently from 72d16fe to fe54b71 Compare November 21, 2019 08:44
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