Skip to content

Commit eccc1a0

Browse files
committed
More doc updates
1 parent 47853a6 commit eccc1a0

2 files changed

Lines changed: 17 additions & 9 deletions

File tree

wgpu-core/src/device/queue.rs

Lines changed: 11 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -642,8 +642,14 @@ impl WebGpuError for QueueSubmitError {
642642
/// surface textures they reference in [`surface_textures`]. Contribute to
643643
/// [`Queue::pending_writes`] as necessary.
644644
///
645-
/// 3) Call the `PendingSubmission`'s [`submit`] method, passing your mutex
646-
/// guard on [`Queue::pending_writes`].
645+
/// 3) Acquire the pending writes lock. This may be done at any point between
646+
/// the return from [`Queue::allocate_submission`] and the call to
647+
/// [`submit`]. Typically it should be done as late as is possible given
648+
/// any necessary pending writes activity.
649+
///
650+
/// 4) Call the `PendingSubmission`'s [`submit`] method (which is a convenience
651+
/// wrapper around [`Queue::submit_pending_submission`]). Pass the pending
652+
/// writes mutex guard to [`submit`].
647653
///
648654
/// It is also acceptable to drop the `PendingSubmission` without submitting;
649655
/// this frees its locks in the appropriate order. This may be necessary when
@@ -657,7 +663,7 @@ impl WebGpuError for QueueSubmitError {
657663
/// - [`Queue::submit`] just submits user-constructed [`CommandBuffer`]s.
658664
///
659665
/// - [`Queue::prepare_surface_texture_for_present`] examines the surface
660-
/// texture being presented, and submit deferred initialization commands and
666+
/// texture being presented, and submits deferred initialization commands and
661667
/// barriers to get it ready.
662668
///
663669
/// - [`Queue::flush_writes_for_buffer`] and [`Queue::flush_pending_writes`]
@@ -693,7 +699,7 @@ pub(crate) struct PendingSubmission<'a> {
693699

694700
/// Surface textures referenced by command buffers in this submission.
695701
///
696-
/// These need to be passed to the [`wgpu_hal::Queue::submit`], which
702+
/// These need to be passed to [`wgpu_hal::Queue::submit`], which
697703
/// requires that the list contains no duplicates, so we store them in a
698704
/// `HashMap` keyed by `SurfaceTexture` address.
699705
surface_textures: FastHashMap<*const Texture, Arc<Texture>>,
@@ -1697,7 +1703,7 @@ impl Queue {
16971703
/// Returns the index and a [`PendingSubmission`].
16981704
///
16991705
/// The caller passes in the already-acquired [`SnatchGuard`]. This function acquires
1700-
/// the fence lock and the command index lock.
1706+
/// the command index lock.
17011707
///
17021708
/// The caller should update [`PendingSubmission::executions`] with details of the
17031709
/// submission.

wgpu-core/src/device/resource.rs

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -710,9 +710,11 @@ impl Device {
710710
/// Note that a `false` result here does *not* guarantee that no further activity will
711711
/// occur on the `Device`. A [`Device`] can be marked invalid at any time, even while
712712
/// locks are held, meaning that operations begun before the `Device` was marked
713-
/// invalid will still generally run to completion. This is simply a consequence of
714-
/// making [`Device::valid`] an `AtomicBool`, rather than an ordinary `bool` field
715-
/// protected by the same locks that all other operations acquire.
713+
/// invalid will still generally run to completion. This is a consequence of
714+
/// making [`Device::valid`] an `AtomicBool`. It could be avoided by making
715+
/// [`Device::valid`] an ordinary `bool` field protected by the same locks that
716+
/// all other operations acquire, but we use an `AtomicBool` because there
717+
/// are many device validity checks and we want those to be cheap.
716718
pub fn is_valid(&self) -> bool {
717719
self.valid.load(Ordering::Acquire)
718720
}
@@ -972,7 +974,7 @@ impl Device {
972974
// However, checking device validity for this purpose is tricky. A device can be
973975
// marked invalid at any time, regardless of what locks are held. This means that,
974976
// even though queue submission does check device validity at the start (in
975-
// `Queue::allocate_submission`), the submission will proceed even if the the
977+
// `Queue::allocate_submission`), the submission will proceed even if the
976978
// device gets marked invalid after that check. Thus, other threads can observe
977979
// the queue becoming non-empty even after they have observed the device to be
978980
// invalid.

0 commit comments

Comments
 (0)