Remove indentation from doc comments.

The indentation in `command/bundle.rs` and `swap_chain.rs` causes
rustdoc to interpret these comments as code, which it then tries to
parse. Removing the indentation persuades it that they are text.
This commit is contained in:
Jim Blandy 2022-08-20 16:29:55 -07:00
parent 4f9e82a77d
commit 7c491c0d14
2 changed files with 41 additions and 41 deletions

View File

@ -4,36 +4,36 @@
/*! Render Bundles /*! 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 User creates a `RenderBundleEncoder` and populates it by issuing commands
from `bundle_ffi` module, just like with `RenderPass`, except that the from `bundle_ffi` module, just like with `RenderPass`, except that the
set of available commands is reduced. Everything is written into a `RawPass`. 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`. Once the commands are encoded, user calls `render_bundle_encoder_finish`.
This is perhaps the most complex part of the logic. It consumes the This is perhaps the most complex part of the logic. It consumes the
commands stored in `RawPass`, while validating everything, tracking the state, commands stored in `RawPass`, while validating everything, tracking the state,
and re-recording the commands into a separate `Vec<RenderCommand>`. It and re-recording the commands into a separate `Vec<RenderCommand>`. It
doesn't actually execute any commands. doesn't actually execute any commands.
What's more important, is that the produced vector of commands is "normalized", 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 which means it can be executed verbatim without any state tracking. More
formally, "normalized" command stream guarantees that any state required by 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 a draw call is set explicitly by one of the commands between the draw call
and the last changing of the pipeline. and the last changing of the pipeline.
### Execution ### Execution
When the bundle is used in an actual render pass, `RenderBundle::execute` is 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 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 buffer. Thanks to the "normalized" property, it doesn't track any bind group
invalidations or index format changes. invalidations or index format changes.
!*/ !*/
#![allow(clippy::reversed_empty_ranges)] #![allow(clippy::reversed_empty_ranges)]

View File

@ -4,32 +4,32 @@
/*! Swap chain management. /*! 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 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 the parent surface, which is backend-independent. This ensures a 1:1 correspondence
between them. between them.
`get_next_image()` requests a new image from the surface. It becomes a part of `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 `TextureViewInner::SwapChain` of the resulted view. The view is registered in the HUB
but not in the device tracker. but not in the device tracker.
The only operation allowed on the view is to be either a color or a resolve attachment. 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. 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. 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 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 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. 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 It always starts with `Uninitialized` and ends with `Present`, so that no barriers are
needed when we need to actually present it. needed when we need to actually present it.
In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap
chain view. 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")] #[cfg(feature = "trace")]