nordic-dev.net/wgpu
nordic-dev.net/wgpu
2
0
Fork 0
mirror of https://github.com/gfx-rs/wgpu.git synced 2024-11-25 00:03:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

v0.7 Fix build failure due to rust-lang/rust PR 99413 (#2966)

Browse Source 
* 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 <jimb@red-bean.com>
This commit is contained in:
Frank Steffahn 2022-08-20 22:33:32 +02:00 committed by GitHub
parent ad2e1b6ff8
commit 39fafde2b6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 44 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
wgpu-core/src/command/bundle.rs
View File

@ -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<RenderCommand>`. 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<RenderCommand>`. 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)]

3
wgpu-core/src/device/mod.rs
View File

@ -1236,6 +1236,7 @@ impl<B: GfxBackend> Device<B> {
// `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<B: GfxBackend> Device<B> {
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() {

38
wgpu-core/src/swap_chain.rs
View File

@ -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")]