Spec changes for atomic vec2u - #5610
Conversation
alan-baker
left a comment
There was a problem hiding this comment.
On the fence about using vec2u in the core spec text. I think we generally expand it out to vec2<u32> (though it is likely used in examples).
I use it as the name of the enable ! |
I think it's ok there. More in the type definition is where I'm less sure. |
|
Previews, as seen when this build job started (19bad54): |
There was a problem hiding this comment.
Feels like this ought to change. No certain how though.
dneto0
left a comment
There was a problem hiding this comment.
My complaints are editorial.
Also, why are there new summaries of WGSL in this patch? Please remove thema.
I have a good idea of what I would write instead; I'll try to coordinate with @petermcneeleychromium to see who should make them.
Don't rely on implied behaviours of bitcasting to u64. Don't use WGSL-like pseucode that isn't actually WGSL.
5a69c30 to
b0870fb
Compare
b0870fb to
d561e5b
Compare
Co-authored-by: alan-baker <alanbaker@google.com>
Co-authored-by: alan-baker <alanbaker@google.com>
Co-authored-by: alan-baker <alanbaker@google.com>
Avoid redundancy.
Original approved proposal
https://github.com/gpuweb/gpuweb/blob/main/proposals/atomic-64-min-max.md
This feature is extremely limited to side effect/mutation in storage buffers.
There is no return value so no way of creating synchronize-with sequencing.