目标将是获得最佳性能，当每个主要计算都在GPU上完成时，使浏览器中的大量模拟成为可能，实现类似 powdertoy 或更高级的。
而且由于 WebGPU 在 chrome 上发布，它可能已经成为可能。但到目前为止我从未做过着色器编程，所以我对所涉及的复杂性有点害怕，但是看一些教程给我的印象是它很简单并且让我对具有逻辑和图形的可能性充满热情在 GPU 上并排运行，而不必返回到 CPU.
所以也许我忽略了一些东西。 ChatGPT 也建议不要这样做，但不能给我任何根本原因，如果我能处理靠近金属的肮脏工作，为什么不可能。
我能找到的是：着色器程序通常非常小。因此，出于某些技术原因，即使我在 WGSL 中实现了所有模拟和 UI 逻辑，它甚至不会使一切变得更快？ （假设我不会犯重大错误，我知道这很容易做到）
那为什么我找不到已经做过某事的人呢？
代码大小是否受限，或者是否有太多控制流元素阻碍了性能，或者仅仅是缺少工具来正确地完成它？
肯定有很多东西要学，比如：
然后我发现一个工作组的规模（操作数量 在单个批次中计算）在代码中设置为与矩阵一样大 边。它工作正常，直到矩阵边低于 WebGPU API 中反映的 GPU 上的 ALU（算术逻辑单元） 作为 maximumWorkingGroupSize 属性。 https://pixelscommander.com/javascript/webgpu-computations-performance-in-comparison-to-webgl/
但就算不优化，应该还是跑赢js和wasm吧？如果没有，为什么不呢？
简短的回答显然是否定的，这是不可能的，因为着色器根本不能在无限循环中运行，如果它们尝试这样做，会在几秒钟后被视为挂起并被操作系统杀死。
所以它们的想法和目的是一次以小块运行。但如果做得好，即使不是全部，大部分繁重的模拟工作确实可以在 GPU 上运行（作为 WGSL 代码），而无需在 GPU 和 CPU 之间来回发送大量数据。只有必要的位。
有迹象表明，WGSL 针对大规模并行化进行了优化，但不适用于 if else 构造的复杂分支，因此 WGSL 代码中的所有游戏逻辑可能会导致更差的性能。如此小的 WGSL 模块，它们处理的模拟数据保留在 GPU 的缓冲区中，显然是我的选择。