mirror of
https://github.com/gfx-rs/wgpu.git
synced 2024-11-21 22:33:49 +00:00
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:
parent
4f9e82a77d
commit
7c491c0d14
@ -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)]
|
||||||
|
|
||||||
|
@ -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")]
|
||||||
|
Loading…
Reference in New Issue
Block a user