Closed Davidyanlong closed 5 months ago
感谢测试反馈 初次内存申请时间长的问题我们已经收到,后续会改进 性能问题来自两个方面:
感谢Orillusion团队的重视,后续的使用学习中希望能得到更多的帮助!
根据https://codepen.io/ShuangLiu/pen/YzEEmLa 的测试,感觉使用mapAsync
的方式优于 writeBuffer
的方式,单独测试mapAsync
与 WebGL的‘bufferSubData’ 几乎差不多,引擎会考虑 mapAsync
的方式吗?
根据https://codepen.io/ShuangLiu/pen/YzEEmLa 的测试,感觉使用
mapAsync
的方式优于writeBuffer
的方式,单独测试mapAsync
与 WebGL的‘bufferSubData’ 几乎差不多,引擎会考虑mapAsync
的方式吗?
mapasync
的理论性能确实好一些,但实际工程化过程中会遇到几个问题:
mapasync
内部及时很快完成,但异步的回调也无法及时在js主线程中触发,导致实际延迟可能比 writebuffer
还高,实际综合表现就是 fps 很不稳定,尤其在有ui操作,网络通信时会有突发的高延迟、卡帧等现象。所以 mapasync
比较难优化,一般较适合一个大内存临时写入或读取时用一下,一般基础的每帧都要更新的buffer,比如 transform 这种,还是用 writebuffer
这种比较有确定性的同步操作更合适mapasync
内部 (Dawn) 的优化机制也不算完善,https://codepen.io/ShuangLiu/pen/YzEEmLa 这个例子已经说明问题,当有其他 webgpu api 操作时,mapasync
的延迟会大大增加,它内部机制也是等待 GPU
空闲状态下才会去进行操作,如果有其他操作正在进行,mapasync
的延迟就会不稳定,尤其是有大量 compute shader
运行时,实际工程中的延迟基本和 writebuffer
相同甚至更大,远不如 webgl
的 bufferSubData
的性能综上,目前用 mapasync
效果可能还不如 writebuffer
,这需要 webgpu
标准的迭代和优化,比如支持多线程的gpu内存写入操作,也需要 Chrome 的内部的实现去优化,释放更多的底层性能,后续我们也会跟进尝试更多的使用 mapasync
的操作场景
感谢 @lslzl3000,您解释的很清楚,学到了。很高兴能得到您的解答.
渲染30万个box, WASM申请内存时间太长, 渲染帧率低于 https://threejs.org/examples/?q=inst#webgl_buffergeometry_instancing_interleaved
分配WASM时间 从10:45:02.927 - 10.45.24.316 用时21秒多![33fa0507bfe4733f8cbe0b54a4a811f](https://github.com/Orillusion/orillusion/assets/10626549/dd69012c-bfc4-44f5-adfa-a6824e59b144)
测试渲染30万了立方体 WASM计算就耗了很多时间,需要改进![d7c5cd56ce1a069d797ea8c1e621cfe](https://github.com/Orillusion/orillusion/assets/10626549/c620b53d-906e-424e-bffc-8f983af06d83)