In reply to @jrprice:matrix.org
The scope of a workgroupBarrier is all invocations in the workgroup. It is likely that the SIMD width of the hardware you are running on would only include a subset of those invocations (depends on the GPU and the workgroup size), and therefore a barrier is necessary.
In the future (post V1), we will have subgroups which will likely align to the SIMD width of the hardware, and a subgroup barrier to synchronize between them would be inexpensive (or free).

In reply to @ghadeer.abousaleh:matrix.org
Portability-related question: this section of the specs is probably the only one that refers to endianness: https://gpuweb.github.io/gpuweb/wgsl/#internal-value-layout ... It suggests little-endianness. Wouldn't this make JavaScript's typed arrays bad for portability of WebGPU apps? I imagine that typed arrays are more efficient than the alternative (data views, which allow you to explicitly specify endianness)

In reply to @stronglynormal:matrix.org

I'm struggling to understand the relationship between atomics, workgroup barriers, and storage barriers. Several questions:

• When doing an atomic operation (ie atomicAdd), does it need to be placed before or after a barrier? For example, if I have 100k shader invocations and call var bar = atomicAdd(&foo, 1); in each one, is it guaranteed that bar will be a unique u32 in each shader that increments by 1 across the set of invocations (ie if the shader runs 200000 times and foo starts at 0 then it will be 200000 by the end and each shader will have a unique bar?), and are barriers necessary to achieve this?
• Where are atomics for workgroups declared? I see how to declare them in storage, ie a storage array<atomic<u32>>, but I'm not sure how/where to declare them for workgroup memory.
• How do storageBarrier and workgroupBarrier work across workgroups? My assumption is that workgroupBarrier only applies to a single workgroup, but does storageBarrier span all workgroups in a dispatch? ie if I do x.dispatchWorkgroups(1024,1024,1024), will all 1073741824 workgroups be run until the storage barrier and then resumed after the last one hits it?
• Are workgroup barriers faster that storage barriers? Are n atomic operations on a workgroup variable faster than n atomic operations across different threads on a storage variable?
• My limited use of atomics has led me to radically different memory profiles - sometimes they hardly matter, and sometimes their use takes me from 60fps to 2fps. Is there an "atomics best practices" set of guidelines that can help plan out where they're most effective (ie how often a single atomic can be interacted with, how many atomics per shader, uniformity and atomics, etc).

Thanks in advance for any advice y'all can give!

In reply to @stronglynormal:matrix.org

I'm struggling to understand the relationship between atomics, workgroup barriers, and storage barriers. Several questions:

• When doing an atomic operation (ie atomicAdd), does it need to be placed before or after a barrier? For example, if I have 100k shader invocations and call var bar = atomicAdd(&foo, 1); in each one, is it guaranteed that bar will be a unique u32 in each shader that increments by 1 across the set of invocations (ie if the shader runs 200000 times and foo starts at 0 then it will be 200000 by the end and each shader will have a unique bar?), and are barriers necessary to achieve this?
• Where are atomics for workgroups declared? I see how to declare them in storage, ie a storage array<atomic<u32>>, but I'm not sure how/where to declare them for workgroup memory.
• How do storageBarrier and workgroupBarrier work across workgroups? My assumption is that workgroupBarrier only applies to a single workgroup, but does storageBarrier span all workgroups in a dispatch? ie if I do x.dispatchWorkgroups(1024,1024,1024), will all 1073741824 workgroups be run until the storage barrier and then resumed after the last one hits it?
• Are workgroup barriers faster that storage barriers? Are n atomic operations on a workgroup variable faster than n atomic operations across different threads on a storage variable?
• My limited use of atomics has led me to radically different memory profiles - sometimes they hardly matter, and sometimes their use takes me from 60fps to 2fps. Is there an "atomics best practices" set of guidelines that can help plan out where they're most effective (ie how often a single atomic can be interacted with, how many atomics per shader, uniformity and atomics, etc).

Thanks in advance for any advice y'all can give!

In reply to @ben-clayton:matrix.org
Unfortunately there is no reliable and portable way - which is the reason they were removed from core.

Ah whoops wrong channel - the buffer looks something like this:

  count: u32,
  data:  array<Light, 32>, 
}```
`Light` has a bunch of things, it adds up to 120 bytes ex padding, not sure if you need that as this behaviour seems to happen no matter what's in there.

Ah whoops wrong channel - the buffer looks something like this:

struct Light {
  count: u32,
  data:  array<Light, 32>, 
}```
`Light` has a bunch of things, it adds up to 120 bytes ex padding, not sure if you need that as this behaviour seems to happen no matter what's in there.

Ah whoops wrong channel - the buffer looks something like this:

struct Light {
  count: u32,
  data:  array<Light, 32>, 
}

Light has a bunch of things, it adds up to 120 bytes ex padding, not sure if you need that as this behaviour seems to happen no matter what's in there.

Ah whoops wrong channel - the buffer looks something like this:

struct Light {
  count: u32,
  data:  array<Light, 32>, 
}

Light has a bunch of things, it adds up to 120 bytes ex padding, not sure if you need that as this behaviour seems to happen no matter what's in there.