From 39fafde2b6b3e013d91d8f3be60cfc0946e5edfe Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sat, 20 Aug 2022 22:33:32 +0200 Subject: [PATCH] v0.7 Fix build failure due to rust-lang/rust PR 99413 (#2966) * Fix build failure due to rust-lang/rust PR 99413 * Remove extraneous indentation from comments. The module comments on `command/bundle.rs` and `swap_chain.rs` are indented by four spaces, which causes rustdoc to try to treat them as code examples and compile them as doctests. Removing the indentation causes rustdoc to treat them as text, as intended. Co-authored-by: Jim Blandy --- wgpu-core/src/command/bundle.rs | 45 +++++++++++++++++---------------- wgpu-core/src/device/mod.rs | 3 ++- wgpu-core/src/swap_chain.rs | 38 ++++++++++++++-------------- 3 files changed, 44 insertions(+), 42 deletions(-) diff --git a/wgpu-core/src/command/bundle.rs b/wgpu-core/src/command/bundle.rs index dcdb5faa3..bee1ba1b7 100644 --- a/wgpu-core/src/command/bundle.rs +++ b/wgpu-core/src/command/bundle.rs @@ -4,36 +4,37 @@ /*! Render Bundles - ## Software implementation +## Software implementation - The path from nothing to using a render bundle consists of 3 phases. +The path from nothing to using a render bundle consists of 3 phases. - ### Initial command encoding +### Initial command encoding - User creates a `RenderBundleEncoder` and populates it by issuing commands - from `bundle_ffi` module, just like with `RenderPass`, except that the - set of available commands is reduced. Everything is written into a `RawPass`. +User creates a `RenderBundleEncoder` and populates it by issuing commands +from `bundle_ffi` module, just like with `RenderPass`, except that the +set of available commands is reduced. Everything is written into a `RawPass`. - ### Bundle baking +### Bundle baking - Once the commands are encoded, user calls `render_bundle_encoder_finish`. - This is perhaps the most complex part of the logic. It consumes the - commands stored in `RawPass`, while validating everything, tracking the state, - and re-recording the commands into a separate `Vec`. It - doesn't actually execute any commands. +Once the commands are encoded, user calls `render_bundle_encoder_finish`. +This is perhaps the most complex part of the logic. It consumes the +commands stored in `RawPass`, while validating everything, tracking the state, +and re-recording the commands into a separate `Vec`. It +doesn't actually execute any commands. - What's more important, is that the produced vector of commands is "normalized", - which means it can be executed verbatim without any state tracking. More - formally, "normalized" command stream guarantees that any state required by - a draw call is set explicitly by one of the commands between the draw call - and the last changing of the pipeline. +What's more important, is that the produced vector of commands is "normalized", +which means it can be executed verbatim without any state tracking. More +formally, "normalized" command stream guarantees that any state required by +a draw call is set explicitly by one of the commands between the draw call +and the last changing of the pipeline. - ### Execution +### Execution + +When the bundle is used in an actual render pass, `RenderBundle::execute` is +called. It goes through the commands and issues them into the native command +buffer. Thanks to the "normalized" property, it doesn't track any bind group +invalidations or index format changes. - When the bundle is used in an actual render pass, `RenderBundle::execute` is - called. It goes through the commands and issues them into the native command - buffer. Thanks to the "normalized" property, it doesn't track any bind group - invalidations or index format changes. !*/ #![allow(clippy::reversed_empty_ranges)] diff --git a/wgpu-core/src/device/mod.rs b/wgpu-core/src/device/mod.rs index c2e2fad52..7f3adb454 100644 --- a/wgpu-core/src/device/mod.rs +++ b/wgpu-core/src/device/mod.rs @@ -1236,6 +1236,7 @@ impl Device { // `BTreeMap` has ordered bindings as keys, which allows us to coalesce // the descriptor writes into a single transaction. + let mut desc_set; // early declaration so it's dropped after write_map let mut write_map = BTreeMap::new(); for entry in desc.entries.iter() { let binding = entry.binding; @@ -1513,7 +1514,7 @@ impl Device { self.desc_allocator .lock() .allocate(&self.raw, &layout.raw, &layout.desc_count, 1)?; - let mut desc_set = desc_sets.pop().unwrap(); + desc_set = desc_sets.pop().unwrap(); // Set the descriptor set's label for easier debugging. if let Some(label) = desc.label.as_ref() { diff --git a/wgpu-core/src/swap_chain.rs b/wgpu-core/src/swap_chain.rs index 262cb3321..74baa2195 100644 --- a/wgpu-core/src/swap_chain.rs +++ b/wgpu-core/src/swap_chain.rs @@ -4,32 +4,32 @@ /*! Swap chain management. - ## Lifecycle +## Lifecycle - At the low level, the swap chain is using the new simplified model of gfx-rs. +At the low level, the swap chain is using the new simplified model of gfx-rs. - A swap chain is a separate object that is backend-dependent but shares the index with - the parent surface, which is backend-independent. This ensures a 1:1 correspondence - between them. +A swap chain is a separate object that is backend-dependent but shares the index with +the parent surface, which is backend-independent. This ensures a 1:1 correspondence +between them. - `get_next_image()` requests a new image from the surface. It becomes a part of - `TextureViewInner::SwapChain` of the resulted view. The view is registered in the HUB - but not in the device tracker. +`get_next_image()` requests a new image from the surface. It becomes a part of +`TextureViewInner::SwapChain` of the resulted view. The view is registered in the HUB +but not in the device tracker. - The only operation allowed on the view is to be either a color or a resolve attachment. - It can only be used in one command buffer, which needs to be submitted before presenting. - Command buffer tracker knows about the view, but only for the duration of recording. - The view ID is erased from it at the end, so that it's not merged into the device tracker. +The only operation allowed on the view is to be either a color or a resolve attachment. +It can only be used in one command buffer, which needs to be submitted before presenting. +Command buffer tracker knows about the view, but only for the duration of recording. +The view ID is erased from it at the end, so that it's not merged into the device tracker. - When a swapchain view is used in `begin_render_pass()`, we assume the start and end image - layouts purely based on whether or not this view was used in this command buffer before. - It always starts with `Uninitialized` and ends with `Present`, so that no barriers are - needed when we need to actually present it. +When a swapchain view is used in `begin_render_pass()`, we assume the start and end image +layouts purely based on whether or not this view was used in this command buffer before. +It always starts with `Uninitialized` and ends with `Present`, so that no barriers are +needed when we need to actually present it. - In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap - chain view. +In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap +chain view. - In `present()` we return the swap chain image back and wait on the semaphore. +In `present()` we return the swap chain image back and wait on the semaphore. !*/ #[cfg(feature = "trace")]