Vulkan嵌套循环场景下subgroupBarrier无法同步子组调用问题咨询

• 该问题并非嵌套循环直接导致，核心诱因是子组线程的控制流发散，不符合subgroupBarrier的调用约束：GLSL中subgroupBarrier要求子组内所有活跃线程必须处于同一条控制流路径，且同时执行到该屏障指令，否则行为未定义。
• 你的代码中不同线程的face_offset值存在差异，进入part>=2结束分支的时间并不一致：先完成面删除逻辑的线程会提前到达屏障位置，此时其余线程仍在外层循环或内层非结束分支中执行，并未触发该屏障调用。多数驱动遇到这种非统一控制流下的子组屏障时，会直接跳过同步逻辑，因此你观察到屏障失效、计数偏小的现象。
• 入口处的屏障可以正常生效，正是因为刚进入main函数时所有线程控制流完全一致，满足屏障的调用条件。
• 额外注意：部分驱动实现中subgroupBarrier仅保证执行时序同步，不会自动保证共享/全局内存的修改对所有子组线程可见，也可能加剧计数错误的问题。

1. 先做子组线程汇合，统一控制流
   调整循环结构，通过子组投票指令确认所有线程都满足结束条件后，再统一退出循环进入结束分支，保证屏障调用时所有子组线程都处于同一路径：

   while(true) {
       bool thread_ready_exit = false;
       while(face_offset >= ending[part]) {
           part++;
           if(part >= 2) {
               thread_ready_exit = true;
               break;
           }
           face_offset = beginning[part] + lID;
           face_to_relocate = faces[face_offset];
       }
       // 等待所有子组线程都准备好退出
       if(subgroupAll(thread_ready_exit)) break;
       
       // 原有面删除逻辑保持不变
       i++;
       if(i==removed_face_count||shared_faces_to_be_removed[i]==face_to_relocate.x) {
           remove_face(face_offset, i);
           face_offset += GROUP_SIZE;
           face_to_relocate = faces[face_offset];
           i = -1;
       }
   }
   // 此时所有线程控制流统一，屏障可正常生效
   

2. 显式补充内存屏障
   在原子操作循环结束后，同时调用执行屏障和内存屏障，保证原子修改的结果对所有子组线程可见：

   // 原子加法循环结束后
   subgroupBarrier();
   subgroupMemoryBarrierShared(); // 针对shared变量的内存屏障，按需替换为全局内存屏障
   

3. 兼容性优化
   由于你已经确认本地工作组大小等于子组大小，也可以替换为workgroupBarrier()+memoryBarrierShared()，驱动兼容性更好，避免部分厂商对子组扩展的实现缺陷。
4. 初始化校验
   确认copied_faces_idx在使用前已正确初始化，例如在main函数入口由0号线程赋值为0，加屏障同步后再使用，避免初始值不确定导致的计数错误。

内容的提问来源于stack exchange，提问作者alagris