Issue(gpuweb/gpuweb#296): Consider merging all read-only usages. Textures may consist of separate [=mipmap levels=] and [=array layers=], which can be used differently at any given time. Each such <dfn dfn>subresource</dfn> is uniquely identified by a-[=texture=], [=mipmap level=], and-(for {{GPUTextureDimension/2d}} textures only) [=array layer=].+[=texture=], [=mipmap level=],+(for {{GPUTextureDimension/2d}} textures only) [=array layer=],+and [=aspect=].

 Issue(gpuweb/gpuweb#296): Consider merging all read-only usages. Textures may consist of separate [=mipmap levels=] and [=array layers=], which can be used differently at any given time. Each such <dfn dfn>subresource</dfn> is uniquely identified by a-[=texture=], [=mipmap level=], and-(for {{GPUTextureDimension/2d}} textures only) [=array layer=].+[=texture=], [=mipmap level=],+(for {{GPUTextureDimension/2d}} textures only) [=array layer=],+and [=aspect=]. -The **main usage rule** is that any [=subresource=]-at any given time can only be in either:+<dfn dfn>atom resource</dfn> means a whole buffer or a single subresource of a texture.++The **main usage rule** is that any [=atom resource=]+at any given time within [=usage scope=] can only be in either:   - a combination of [=read-only usage=]s   - a single [=mutating usage=] +The only exception is that a combination of writeonly-storage-texture usages, or a combination

 pub type Bytes = u8;  /// Number of components in a vector. #[repr(u8)]-#[derive(Clone, Copy, Debug, PartialEq)]+#[derive(Clone, Copy, Debug, PartialEq, Hash, Eq)]

 impl Writer {                             crate::TypeInner::Vector { size, kind, width } => {                                 vector_id = Some(left_id);                                 for (k, v) in self.lookup_type.iter() {

 impl Writer {                             crate::TypeInner::Vector { size, kind, width } => {                                 vector_id = Some(right_id);                                 for (k, v) in self.lookup_type.iter() {

 impl Writer {          let instruction; -        match ty.inner {+        match ty.inner.clone() {

 impl Writer {     /// Primitive Instructions     /// -    fn parse_type_declaration(+    fn write_scalar(&self, id: Word, kind: crate::ScalarKind, width: u8) -> Instruction {+        match kind {+            crate::ScalarKind::Sint => {+                self.instruction_type_int(id, (width * BITS_PER_BYTE) as u32, Signedness::Signed)

 impl Writer {     /// Primitive Instructions     /// -    fn parse_type_declaration(+    fn write_scalar(&self, id: Word, kind: crate::ScalarKind, width: u8) -> Instruction {+        match kind {+            crate::ScalarKind::Sint => {+                self.instruction_type_int(id, (width * BITS_PER_BYTE) as u32, Signedness::Signed)+            }+            crate::ScalarKind::Uint => {+                self.instruction_type_int(id, (width * BITS_PER_BYTE) as u32, Signedness::Unsigned)+            }+            crate::ScalarKind::Float => {+                self.instruction_type_float(id, (width * BITS_PER_BYTE) as u32)+            }+            crate::ScalarKind::Bool => self.instruction_type_bool(id),+        }+    }++    fn get_or_create_scalar(+        &mut self,+        arena: &crate::Arena<crate::Type>,+        kind: crate::ScalarKind,+        width: u8,+    ) -> Word {+        if let Some(handle) = self.find_scalar_handle(arena, kind, width) {+            self.get_type_id(arena, handle)+        } else {+            let (instruction, id) =+                self.write_type_declaration_local(arena, LocalType::Scalar { kind, width });+            self.lookup_type+                .insert(LookupType::Local(LocalType::Scalar { kind, width }), id);+            instruction.to_words(&mut self.logical_layout.declarations);+            id+        }+    }++    fn get_or_create_vector(+        &mut self,+        arena: &crate::Arena<crate::Type>,+        size: crate::VectorSize,+        kind: crate::ScalarKind,+        width: u8,+    ) -> Word {+        if let Some(handle) = self.find_vector_handle(arena, size, kind, width) {+            self.get_type_id(arena, handle)+        } else {+            let (instruction, id) = self.write_type_declaration_local(+                arena,+                LocalType::Vector {+                    size,+                    kind,+                    width,+                },+            );+            self.lookup_type.insert(+                LookupType::Local(LocalType::Vector {+                    size,+                    kind,+                    width,+                }),+                id,+            );+            instruction.to_words(&mut self.logical_layout.declarations);+            id+        }+    }++    fn parse_to_spirv_storage_class(&self, class: crate::StorageClass) -> spirv::StorageClass {+        match class {+            crate::StorageClass::Constant => spirv::StorageClass::UniformConstant,+            crate::StorageClass::Function => spirv::StorageClass::Function,+            crate::StorageClass::Input => spirv::StorageClass::Input,+            crate::StorageClass::Output => spirv::StorageClass::Output,+            crate::StorageClass::Private => spirv::StorageClass::Private,+            crate::StorageClass::StorageBuffer => spirv::StorageClass::StorageBuffer,+            crate::StorageClass::Uniform => spirv::StorageClass::Uniform,+            crate::StorageClass::WorkGroup => spirv::StorageClass::Workgroup,+        }+    }++    fn write_type_declaration_local(+        &mut self,+        arena: &crate::Arena<crate::Type>,+        local_ty: LocalType,+    ) -> (Instruction, Word) {+        let id = self.generate_id();+        match local_ty {+            LocalType::Scalar { kind, width } => (self.write_scalar(id, kind, width), id),+            LocalType::Vector { size, kind, width } => (+                {+                    let scalar_id = self.get_or_create_scalar(arena, kind, width);+                    self.instruction_type_vector(id, scalar_id, size)+                },+                id,+            ),+            _ => unimplemented!(),

 impl Writer {                 _ => continue,             }         }-        scalar_handle.unwrap()+        scalar_handle+    }++    fn find_vector_handle(

 Expose a subset of subgroup operations in WGSL shaders:   - <Quadgroup Extension>: If quad operations are made into their own                            extension, both its potential market becomes                            larger and subgroup operations' market grows.+    +> <Viable>

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.+  + <Standard Library>: Since subgroup operations are common across+                        all three APIs, they were to be considered+                        for [issue #667](https://github.com/gpuweb/gpuweb/issues/667).+  + <Performance>: [Proven contribution](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/)+                   to general purpose algorithms.+  + <Viable>: There is a safe subset of subgroup operations.+++[Extension]: Subgroup operations should be exposed as an extension.+  + <Target>: Subgroup operations are not available on all WebGPU+              target hardware.++[Host Interface]: Subgroup size control and statistics should be exposed.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.+  + <Standard Library>: Since subgroup operations are common across+                        all three APIs, they were to be considered+                        for [issue #667](https://github.com/gpuweb/gpuweb/issues/667).+  + <Performance>: [Proven contribution](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/)+                   to general purpose algorithms.+  + <Viable>: There is a safe subset of subgroup operations.+++[Extension]: Subgroup operations should be exposed as an extension.+  + <Target>: Subgroup operations are not available on all WebGPU+              target hardware.++[Host Interface]: Subgroup size control and statistics should be exposed.+  - <Pipeline Statistics>: Exact subgroup size can't be queried in DirectX 12.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.+  + <Standard Library>: Since subgroup operations are common across+                        all three APIs, they were to be considered+                        for [issue #667](https://github.com/gpuweb/gpuweb/issues/667).+  + <Performance>: [Proven contribution](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/)

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.+  + <Standard Library>: Since subgroup operations are common across+                        all three APIs, they were to be considered+                        for [issue #667](https://github.com/gpuweb/gpuweb/issues/667).+  + <Performance>: [Proven contribution](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/)+                   to general purpose algorithms.+  + <Viable>: There is a safe subset of subgroup operations.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.+[Motivation]: We should have subgroup operations.+  + <Standard Library>: Since subgroup operations are common across+                        all three APIs, they were to be considered

 pub enum MemberOrigin {  /// Member of a user-defined structure. // Clone is used only for error reporting and is not intended for end users-#[derive(Clone, Debug, PartialEq)]+#[derive(Clone, Debug, PartialEq, Hash, Eq)]

 pub struct Type {  /// Enum with additional information, depending on the kind of type. // Clone is used only for error reporting and is not intended for end users-#[derive(Clone, Debug, PartialEq)]+#[derive(Clone, Debug, PartialEq, Hash, Eq)]

 enum Signedness {     Signed = 1, } -#[derive(Debug)]+#[derive(Hash, Eq, PartialEq, Debug)] enum LocalType {     Scalar(crate::TypeInner),

 spirv = { package = "spirv_headers", version = "1.4.2", optional = true } glsl = { version = "4.1", optional = true } pomelo = { version = "0.1.4", optional = true } thiserror = "1.0"+daggy = "*"

 impl<I: Iterator<Item = u32>> Parser<I> {                 Instruction { op, .. } => return Err(Error::InvalidParameter(op)),             }         }-        // read body++        // Read body         let mut local_function_calls = FastHashMap::default();-        let mut control_flow_graph = FastHashMap::default();+        let mut control_flow_graph = Dag::<ControlFlowNode, ControlFlowEdge, u32>::new();+        let mut id_to_node = std::collections::HashMap::<u32, NodeIndex<u32>>::new();++        // Scan the blocks and add them as nodes         loop {             let fun_inst = self.next_inst()?;             log::debug!("\t\t{:?}", fun_inst.op);             match fun_inst.op {                 spirv::Op::Label => {+                    // Read the label ID                     fun_inst.expect(2)?;                     let label_id = self.next()?;+                     let node = self.next_block(+                        label_id,                         &mut fun.expressions,                         &mut fun.local_variables,                         &module.types,                         &module.constants,                         &module.global_variables,                         &mut local_function_calls,                     )?;-                    // temp until the CFG is fully processed-                    for assign in node.assignments.iter() {-                        fun.body.push(crate::Statement::Store {-                            pointer: assign.to,-                            value: assign.value,-                        });-                    }-                    match node.terminator {-                        Terminator::Return { value } => {-                            fun.body.push(crate::Statement::Return { value });-                        }-                        Terminator::Branch {-                            label_id,-                            condition,-                        } => {-                            let _ = (label_id, condition); //TODO-                        }-                    }-                    control_flow_graph.insert(label_id, node);++                    id_to_node.insert(label_id, control_flow_graph.add_node(node));                 }                 spirv::Op::FunctionEnd => {                     fun_inst.expect(1)?;                     break;                 }-                _ => return Err(Error::UnsupportedInstruction(self.state, fun_inst.op)),+                _ => panic!("SHOULD NOT HAPPEN"),+            }+        }++        // Create Edges.+        let mut edges = Vec::new();+        for node in control_flow_graph.node_weights_mut() {

 struct LookupSampledImage {     image: Handle<crate::Expression>,     sampler: Handle<crate::Expression>, }- struct DeferredFunctionCall {     source_handle: Handle<crate::Function>,     expr_handle: Handle<crate::Expression>,     dst_id: spirv::Word, }--enum Terminator {+pub enum Merge {+    Selection {+        merge_block_id: spirv::Word,

 struct LookupSampledImage {     image: Handle<crate::Expression>,     sampler: Handle<crate::Expression>, }- struct DeferredFunctionCall {     source_handle: Handle<crate::Function>,     expr_handle: Handle<crate::Expression>,     dst_id: spirv::Word, }--enum Terminator {+pub enum Merge {

 impl<I: Iterator<Item = u32>> Parser<I> {                 Instruction { op, .. } => return Err(Error::InvalidParameter(op)),             }         }-        // read body++        // Read body         let mut local_function_calls = FastHashMap::default();-        let mut control_flow_graph = FastHashMap::default();+        let mut control_flow_graph = Dag::<ControlFlowNode, ControlFlowEdge, u32>::new();+        let mut id_to_node = std::collections::HashMap::<u32, NodeIndex<u32>>::new();++        // Scan the blocks and add them as nodes         loop {             let fun_inst = self.next_inst()?;             log::debug!("\t\t{:?}", fun_inst.op);             match fun_inst.op {                 spirv::Op::Label => {+                    // Read the label ID                     fun_inst.expect(2)?;                     let label_id = self.next()?;+                     let node = self.next_block(+                        label_id,                         &mut fun.expressions,                         &mut fun.local_variables,                         &module.types,                         &module.constants,                         &module.global_variables,                         &mut local_function_calls,                     )?;-                    // temp until the CFG is fully processed-                    for assign in node.assignments.iter() {-                        fun.body.push(crate::Statement::Store {-                            pointer: assign.to,-                            value: assign.value,-                        });-                    }-                    match node.terminator {-                        Terminator::Return { value } => {-                            fun.body.push(crate::Statement::Return { value });-                        }-                        Terminator::Branch {-                            label_id,-                            condition,-                        } => {-                            let _ = (label_id, condition); //TODO-                        }-                    }-                    control_flow_graph.insert(label_id, node);++                    id_to_node.insert(label_id, control_flow_graph.add_node(node));                 }                 spirv::Op::FunctionEnd => {                     fun_inst.expect(1)?;                     break;                 }-                _ => return Err(Error::UnsupportedInstruction(self.state, fun_inst.op)),+                _ => panic!("SHOULD NOT HAPPEN"),+            }+        }++        // Create Edges.+        let mut edges = Vec::new();+        for node in control_flow_graph.node_weights_mut() {+            let source_node_index = id_to_node[&node.id];++            match node.terminator {+                Terminator::Branch { target_id } => {+                    let target_node_index = id_to_node[&target_id];++                    edges.push((+                        source_node_index,+                        target_node_index,+                        ControlFlowEdge::Forward,+                    ));+                }+                Terminator::BranchConditional {+                    true_id, false_id, ..+                } => {+                    let true_node_index = id_to_node[&true_id];+                    let false_node_index = id_to_node[&false_id];++                    edges.push((source_node_index, true_node_index, ControlFlowEdge::IfTrue));+                    edges.push((+                        source_node_index,+                        false_node_index,+                        ControlFlowEdge::IfFalse,+                    ));+                }+                _ => {}             }         }+        for edge in edges {

 TODO: would be nice to find ways that avoid looking up as much  !*/ +use std::convert::TryFrom;++use crate::front::spv_dag::*; use crate::{     arena::{Arena, Handle},     FastHashMap, FastHashSet, }; +use daggy::petgraph::*;

 impl<I: Iterator<Item = u32>> Parser<I> {                 Instruction { op, .. } => return Err(Error::InvalidParameter(op)),             }         }-        // read body++        // Read body         let mut local_function_calls = FastHashMap::default();-        let mut control_flow_graph = FastHashMap::default();+        let mut control_flow_graph = Dag::<ControlFlowNode, ControlFlowEdge, u32>::new();+        let mut id_to_node = std::collections::HashMap::<u32, NodeIndex<u32>>::new();++        // Scan the blocks and add them as nodes         loop {             let fun_inst = self.next_inst()?;             log::debug!("\t\t{:?}", fun_inst.op);             match fun_inst.op {                 spirv::Op::Label => {+                    // Read the label ID                     fun_inst.expect(2)?;                     let label_id = self.next()?;+                     let node = self.next_block(+                        label_id,                         &mut fun.expressions,                         &mut fun.local_variables,                         &module.types,                         &module.constants,                         &module.global_variables,                         &mut local_function_calls,                     )?;-                    // temp until the CFG is fully processed-                    for assign in node.assignments.iter() {-                        fun.body.push(crate::Statement::Store {-                            pointer: assign.to,-                            value: assign.value,-                        });-                    }-                    match node.terminator {-                        Terminator::Return { value } => {-                            fun.body.push(crate::Statement::Return { value });-                        }-                        Terminator::Branch {-                            label_id,-                            condition,-                        } => {-                            let _ = (label_id, condition); //TODO-                        }-                    }-                    control_flow_graph.insert(label_id, node);++                    id_to_node.insert(label_id, control_flow_graph.add_node(node));                 }                 spirv::Op::FunctionEnd => {                     fun_inst.expect(1)?;                     break;                 }-                _ => return Err(Error::UnsupportedInstruction(self.state, fun_inst.op)),+                _ => panic!("SHOULD NOT HAPPEN"),

 TODO: would be nice to find ways that avoid looking up as much  !*/ +use std::convert::TryFrom;++use crate::front::spv_dag::*;

 spirv = { package = "spirv_headers", version = "1.4.2", optional = true } glsl = { version = "4.1", optional = true } pomelo = { version = "0.1.4", optional = true } thiserror = "1.0"+daggy = "*"

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,+              subgroup operations are common+              across all three APIs.+  + <Performance>: Proven contribution to+                   general purpose algorithms.+  + <Safe>: There is a safe subset of+            subgroup operations.+++[Extension]: Subgroup operations should be+             exposed as an extension.+  + <Target>: Subgroup operations are not available+              on all WebGPU target hardware.++[Device Only]: Host statistics for subgroup+               operations are not common+               across all three APIs.++[Compute Only]: Subgroup operations should only+                work in compute kernels.+  + <Hardware>: Restricting to compute only increases+                market (e.g., Adreno).+  + <Definition>: Operations are better defined+                  for compute. And this makes helper+                  invocations irrelevant.++[No Shuffle Operations]: Shuffle operations should be excluded.

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,+              subgroup operations are common+              across all three APIs.+  + <Performance>: Proven contribution to+                   general purpose algorithms.+  + <Safe>: There is a safe subset of+            subgroup operations.+++[Extension]: Subgroup operations should be+             exposed as an extension.+  + <Target>: Subgroup operations are not available+              on all WebGPU target hardware.++[Device Only]: Host statistics for subgroup

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,+              subgroup operations are common+              across all three APIs.+  + <Performance>: Proven contribution to+                   general purpose algorithms.+  + <Safe>: There is a safe subset of

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,+              subgroup operations are common+              across all three APIs.+  + <Performance>: Proven contribution to+                   general purpose algorithms.+  + <Safe>: There is a safe subset of+            subgroup operations.+++[Extension]: Subgroup operations should be+             exposed as an extension.+  + <Target>: Subgroup operations are not available+              on all WebGPU target hardware.++[Device Only]: Host statistics for subgroup+               operations are not common+               across all three APIs.++[Compute Only]: Subgroup operations should only+                work in compute kernels.+  + <Hardware>: Restricting to compute only increases+                market (e.g., Adreno).+  + <Definition>: Operations are better defined+                  for compute. And this makes helper+                  invocations irrelevant.++[No Shuffle Operations]: Shuffle operations should be excluded.+  + <DirectX>: DirectX doesn't have shuffle operations.+  + <Support>: Not having shuffle operations+               increases support (e.g., ARM).++[No Quad Operations]: Quad operations should be their+                      own extension.+  + <Market>: If quad operations are made into their+              own extension, both its potential market+              becomes larger and subgroup operations'+              market grows.++[No Explicit Operations]: Indexed or masked operations

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,

 Expose a subset of subgroup operations in WGSL shaders:   - PR: https://github.com/gpuweb/gpuweb/pull/954 --> -[Extension]: We should have an extension to expose subgroup operations.-  + <Performance>: depending on a workload and the platform, it's possible to run [multiple times](https://developer.nvidia.com/blog/cuda-pro-tip-optimized-filtering-warp-aggregated-atomics/) faster.-  + <Support>: all 3 target APIs have some variation of subgroup operations, optionally.--[Size Control]: We should let the developer to control the size of subgroups (in compute workloads).-  + Vulkan has [VK_EXT_subgroup_size_control](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_subgroup_size_control.html) extension to control the size.-  - D3D12 and Metal don't allow to control the size.--[Size Query]: We should allow the developer to query the subgroup size from a compute pipeline.-  + Vulkan has [VK_KHR_pipeline_executable_properties](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_pipeline_executable_properties.html) extension to query the size.-  + Metal has [threadExecutionWidth](https://developer.apple.com/documentation/metal/mtlcomputepipelinestate/1414911-threadexecutionwidth) to query the size.-  - D3D12 doesn't have anything to query the exact size.-  - <Useless>: it's not actionable in Vulkan and D3D12, unlike Metal where we can control the workgroup size from the API.--[Quad Ops]: We should expose the quad operations in fragment shaders.-  - new Adreno and PowerVR hardware doesn't support this-//TODO: fill this out more--[Non-uniform]: We should support the non-uniform subgroup model.-  + <Everywhere>: Vulkan, D3D, and Metal use a non-uniform model.-  - <Ambiguous Divergence>: when invocations in a subgroup are executing "together", how long is that guaranteed?-  - <Ambiguous Reconvergence>: once invocations diverge, what are the guarantees about where you reconverge?-    + Vulkan has weak guarantees, D3D12 and Metal don't have anything.-    - we can just say invocations never reconverge, which matches AMD ISA and CUDA models.-  - <Ambiguous Forward Progress>: how blocks affect progress of other blocks, and invocations within blocks affect progress on other invocations?-    + D3D, Metal, and Vulkan are silent on both of these.-  - <Ambiguous Helpers>: do helper invocations participate in subgroup operations?+[Motivation]: This PR works towards issue #667,+              subgroup operations are common+              across all three APIs.+  + <Performance>: Proven contribution to

 impl Writer {         arena: &crate::Arena<crate::Type>,         handle: crate::Handle<crate::Type>,     ) -> Word {-        match self.lookup_type.lookup_id(handle) {-            Some(word) => word,-            None => {-                let (instruction, id) = self.parse_type_declaration(arena, handle);-                instruction.to_words(&mut self.logical_layout.declarations);-                id-            }+        let ty = &arena[handle];++        if let Some(id) = self+            .lookup_type_new+            .iter()+            .find(|&(_, v)| match v {

 pub struct Writer {     annotations: Vec<Instruction>,     writer_flags: WriterFlags,     void_type: Option<u32>,-    lookup_type: FastHashMap<Word, crate::Handle<crate::Type>>,+    lookup_type_new: FastHashMap<Word, LookupType>,

 impl Writer {     /// Primitive Instructions     /// +    fn parse_type_declaration_local(&mut self, local_ty: LocalType) -> (Instruction, Word) {

 impl Writer {         arena: &crate::Arena<crate::Type>,         handle: crate::Handle<crate::Type>,     ) -> Word {-        match self.lookup_type.lookup_id(handle) {-            Some(word) => word,-            None => {-                let (instruction, id) = self.parse_type_declaration(arena, handle);-                instruction.to_words(&mut self.logical_layout.declarations);-                id-            }+        let ty = &arena[handle];++        if let Some(id) = self+            .lookup_type_new+            .iter()+            .find(|&(_, v)| match v {

 pub struct Writer {     annotations: Vec<Instruction>,     writer_flags: WriterFlags,     void_type: Option<u32>,-    lookup_type: FastHashMap<Word, crate::Handle<crate::Type>>,+    lookup_type_new: FastHashMap<Word, LookupType>,

 enum Signedness {     Signed = 1, } +#[derive(Debug)]+enum LocalType {

 pub enum WebGPURequest {     },     CopyBufferToBuffer {

 enum GPUStoreOp {      : <dfn>drawIndirect(indirectBuffer, indirectOffset)</dfn>     ::+        Draws primitives using parameters read from a {{GPUBuffer}}.++        The <dfn dfn>indirect draw parameters</dfn> encoded in the buffer must be a tightly+        packed block of **four 32-bit unsigned integer values (16 bytes total)**, given in the same+        order as the arguments for {{GPURenderEncoderBase/draw()}}. Written as a C struct,+        the data layout would be:++        ```c+        struct GPUDrawIndirectParameters {+            uint32_t vertexCount;+            uint32_t instanceCount;+            uint32_t firstVertex;+            uint32_t firstInstance;+        };+        ```          <div algorithm="GPURenderEncoderBase.drawIndirect">             **Called on:** {{GPURenderEncoderBase}} this.              **Arguments:**             <pre class=argumentdef for="GPURenderEncoderBase/drawIndirect(indirectBuffer, indirectOffset)">-                indirectBuffer:-                indirectOffset:+                |indirectBuffer|: Buffer containing the [=indirect draw parameters=].+                |indirectOffset|: Offset in bytes into |indirectBuffer| where the drawing data begins.             </pre>              **Returns:** void -            Issue: Describe {{GPURenderEncoderBase/drawIndirect()}} algorithm steps.+            Issue the following steps on the [=Queue timeline=] of |this|:+            <div class=queue-timeline>+                1. If any of the following conditions are unsatisfied, generate a+                    {{GPUValidationError}} error and stop.+                    <div class=validusage>+                        - |indirectBuffer| is [=valid=].+                        - |indirectBuffer|.{{GPUObjectBase/[[device]]}} is |this|.+                        - |indirectOffset| + sizeof([=indirect draw parameters=]) &le;+                            |indirectBuffer|.{{GPUBuffer/[[size]]}}.++                        Issue: Does |indirectOffset| need a particular alignment?

 enum GPUStoreOp {      : <dfn>drawIndexed(indexCount, instanceCount, firstIndex, baseVertex, firstInstance)</dfn>     ::+        Draws indexed primitives.          <div algorithm="GPURenderEncoderBase.drawIndexed">             **Called on:** {{GPURenderEncoderBase}} this.              **Arguments:**             <pre class=argumentdef for="GPURenderEncoderBase/drawIndexed(indexCount, instanceCount, firstIndex, baseVertex, firstInstance)">-                indexCount:-                instanceCount:-                firstIndex:-                baseVertex:-                firstInstance:+                indexCount: The number of indices to draw.+                instanceCount: The number of instances to draw.+                firstIndex: Index to begin drawing from.

 enum GPUStoreOp { <dl dfn-type=method dfn-for=GPURenderEncoderBase>     : <dfn>setPipeline(pipeline)</dfn>     ::+        Sets the current {{GPURenderPipeline}}.          <div algorithm="GPURenderEncoderBase.setPipeline">             **Called on:** {{GPURenderEncoderBase}} this.              **Arguments:**             <pre class=argumentdef for="GPURenderEncoderBase/setPipeline(pipeline)">-                pipeline:+                |pipeline|: The render pipeline to use for subsequent drawing commands.             </pre>              **Returns:** void -            Issue: Describe {{GPURenderEncoderBase/setPipeline()}} algorithm steps.+            Issue the following steps on the [=Queue timeline=] of |this|:

 enum GPUStoreOp {      : <dfn>drawIndirect(indirectBuffer, indirectOffset)</dfn>     ::+        Draws primitives using parameters read from a {{GPUBuffer}}.++        The <dfn dfn>indirect draw parameters</dfn> encoded in the buffer must be a tightly+        packed block of **four 32-bit unsigned integer values (16 bytes total)**, given in the same+        order as the arguments for {{GPURenderEncoderBase/draw()}}. Written as a C struct,