diff --git a/wgpu-core/src/command/bundle.rs b/wgpu-core/src/command/bundle.rs index 05b4626cc..daed94f4e 100644 --- a/wgpu-core/src/command/bundle.rs +++ b/wgpu-core/src/command/bundle.rs @@ -4,36 +4,36 @@ /*! 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/swap_chain.rs b/wgpu-core/src/swap_chain.rs index 568e8ed7c..aa747edc1 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")]