[FR]: 海量渲染WASM 申请内存时间太长 about orillusion HOT 5 CLOSED

根据https://codepen.io/ShuangLiu/pen/YzEEmLa 的测试，感觉使用mapAsync 的方式优于 writeBuffer 的方式，单独测试mapAsync 与 WebGL的‘bufferSubData’ 几乎差不多，引擎会考虑 mapAsync的方式吗？

mapasync 的理论性能确实好一些，但实际工程化过程中会遇到几个问题:

1. 大量同步操作变成异步操作会增加代码结构复杂度，不方便开发调试和维护
2. js的单线程队列回调机制在实时渲染这种场景下，异步回调难以保证实时性和顺序，会受到其它异步操作或事件的干扰，即使mapasync 内部及时很快完成，但异步的回调也无法及时在js主线程中触发，导致实际延迟可能比 writebuffer 还高，实际综合表现就是 fps 很不稳定，尤其在有ui操作，网络通信时会有突发的高延迟、卡帧等现象。所以 mapasync 比较难优化，一般较适合一个大内存临时写入或读取时用一下，一般基础的每帧都要更新的buffer，比如 transform 这种，还是用 writebuffer 这种比较有确定性的同步操作更合适
3. Chrome mapasync 内部 (Dawn) 的优化机制也不算完善，https://codepen.io/ShuangLiu/pen/YzEEmLa 这个例子已经说明问题，当有其他 webgpu api 操作时，mapasync 的延迟会大大增加，它内部机制也是等待 GPU 空闲状态下才会去进行操作，如果有其他操作正在进行，mapasync 的延迟就会不稳定，尤其是有大量 compute shader 运行时，实际工程中的延迟基本和 writebuffer 相同甚至更大，远不如 webgl 的 bufferSubData 的性能

综上，目前用 mapasync 效果可能还不如 writebuffer，这需要 webgpu 标准的迭代和优化，比如支持多线程的gpu内存写入操作，也需要 Chrome 的内部的实现去优化，释放更多的底层性能，后续我们也会跟进尝试更多的使用 mapasync 的操作场景

from orillusion.

感谢测试反馈
初次内存申请时间长的问题我们已经收到，后续会改进
性能问题来自两个方面：

1. 目前 wasm 在 devtools 开启时会有额外的消耗，性能会降低，可以关掉devtools后进行测试
2. chrome webgpu 目前对于写入 gpu 内存的性能存在问题，比如 https://bugs.chromium.org/p/chromium/issues/detail?id=1298309&no_tracker_redirect=1
   目前性能是比不上 webgl 的API的，所以对于大量transfrom的更新，速度可能比 three 还慢一些，这个需要chrome底层去优化更新

from orillusion.

感谢Orillusion团队的重视，后续的使用学习中希望能得到更多的帮助！

from orillusion.

根据https://codepen.io/ShuangLiu/pen/YzEEmLa 的测试，感觉使用mapAsync 的方式优于 writeBuffer 的方式，单独测试mapAsync 与 WebGL的‘bufferSubData’ 几乎差不多，引擎会考虑 mapAsync的方式吗？

from orillusion.

感谢 @lslzl3000，您解释的很清楚，学到了。很高兴能得到您的解答.

from orillusion.