cubecl_core/frontend/
synchronization.rs

1use crate::frontend::CubeContext;
2use crate::ir::Synchronization;
3// Among all backends, the memory order guarantee of WebGPU is the weakest
4// So Cubecl's memory order cannot be stronger than that of WebGPU
5
6/// # Coordinates the following among all invocations in the current cube:
7///
8/// * Memory writes to variables in cube address space(shared memory) complete,
9///   e.g. writes that were initiated actually land in the cube address space memory.
10///
11/// * Then all the invocations in the cube wait for each other to arrive at the barrier, i.e. this step.
12///
13/// * Then all the invocations int the cube begin executing after the barrier, and all writes to cube address space made before the barrier are now visible to any invocation in this cube.
14pub fn sync_units() {}
15
16pub mod sync_units {
17    use super::*;
18
19    pub fn expand(context: &mut CubeContext) {
20        context.register(Synchronization::SyncUnits)
21    }
22}
23
24/// * Sync_storage is the same but change "cube address space(shared memory)" to "storage address space(input args)". But the set of invocations that are collaborating is still only the invocations in the same cube.
25///
26/// * There is no guarantee about using barriers alone to make the writes to storage buffer in one cube become visible to invocations in a different cube.
27pub fn sync_storage() {}
28
29pub mod sync_storage {
30    use super::*;
31
32    pub fn expand(context: &mut CubeContext) {
33        context.register(Synchronization::SyncStorage)
34    }
35}
cubecl_core/frontend/synchronization.rs

cubecl_core/frontend/
synchronization.rs
