From 07cf7897b167c448d1ae82a9989f1bd72eb55fac Mon Sep 17 00:00:00 2001 From: Carter Anderson Date: Wed, 15 Apr 2020 11:58:33 -0700 Subject: [PATCH] add additional context to wgpu resource threading docs --- bevy_wgpu/src/wgpu_resources.rs | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/bevy_wgpu/src/wgpu_resources.rs b/bevy_wgpu/src/wgpu_resources.rs index 8887e8ef0e..9047c96dce 100644 --- a/bevy_wgpu/src/wgpu_resources.rs +++ b/bevy_wgpu/src/wgpu_resources.rs @@ -30,13 +30,15 @@ pub struct WgpuBindGroupInfo { /// pass. /// /// The biggest implication of this design (other than the additional boilerplate here) is that beginning a render pass -/// blocks writes to these resources. This means that if the pass attempts to write any resource, a deadlock will occur. It also means +/// blocks writes to these resources. This means that if the pass attempts to write any resource, a deadlock will occur. WgpuResourceRefs +/// only has immutable references, so the only way to make a deadlock happen is to access WgpuResources directly in the pass. It also means /// that other threads attempting to write resources will need to wait for pass encoding to finish. Almost all writes should occur before -/// passes start, so this hopefully won't be a problem. +/// passes start, so this hopefully won't be a problem. /// -/// It is worth comparing the performance of this to transactional / copy-based approach. This design lock based design guarantees +/// It is worth comparing the performance of this to transactional / copy-based approaches. This lock based design guarantees /// consistency, doesn't perform redundant allocations, and only blocks when a write is occurring. A copy based approach would -/// never block, but would require more allocations / state-synchronization, which I expect will be more expensive. +/// never block, but would require more allocations / state-synchronization, which I expect will be more expensive. It would also be +/// "eventually consistent" instead of "strongly consistent". /// /// Single threaded implementations don't need to worry about these lifetimes constraints at all. RenderPasses can use a RenderContext's /// WgpuResources directly. RenderContext already has a lifetime greater than the RenderPass.