Three.js vs Babylon.js vs Orillusion - Box 渲染测试

admin

测试平台

MacOS - v12.01
Chrome canary - v 96 - 101
Processor - Core i7 8700k, 6-Core, 3.7Ghz
Memory - 16GB 2677MHz DDR4
Graphics - Intel UHD Graphics 630

测试项目

使用 Three.js r133, Babylon.js 5.0.0 preview, Orillusion 进行对比测试
创建多个独立 box with basic color material，用 WebGL 和 WebGPU 进行旋转渲染测试
在 800 x 600 分辨率下，对比 box 创建时间 & 渲染帧率 & 内存消耗

DEMO地址

https://contrast.orillusion.com

测试结果

WebGL 渲染

WebGPU 渲染

Orillusion WebGPU 渲染

单独列出orillusion, 因为1w+数量 three 和 babylon 已无法完成正常帧率渲染

说明：

Orillusion默认开启多线程计算，n 代表 worker 数量，测试6个线程，整体内存消耗在 10-20 MB
此结果仅为Mac OS测试结果，同配置的window电脑，得益于dx12的特性，性能可增加25% ~ 50%， Intel 集显 uhd630 在 15w 数量下渲染也可保持 60 fps
以上测试为Intel普通集显环境，欢迎补充更多机型的测试结果，得益于WebGPU对底层驱动的适配，如果使用rtx独立显卡，相对WebGL将有更大幅度的性能提升
目前 Chrome v94-v101 对 WebGPU 的优化还没有完成，尤其是writeBuffer 和 mapAsync 的性能，相对于 WebGL 的 bufferSubData，在大数据量的写入场景下慢2-10x (详情可参考 https://forum.orillusion.com/topic/39/chrome-writebuffer-performance)，所以目前的 Orillusion 10w+ 的测试中，拖垮 FPS 的是 writeBuffer 的速度。以30w数据量举例，Orillusion 引擎在 CPU 侧处理所有数据（包括逻辑运算，transform，camera，gpu数据装配等）的速度只有不到10ms，理论fps应该保持60 FPS+，但跟 GPU 同步数据的时间，无论使用 writeBuffer 还是 mapAsync 都要30-50ms，完全拖垮了fps。而相同的数量级下，WebGL 的 bufferSubData 只需要 2-3 ms。Three.js/Babylon.js 整体 FPS 低，除了没有对渲染管线做优化，主要是引擎侧在 CPU 处理数据速度太慢造成的。

测试总结

默认参数/优化下，Three.js 性能强于 Babylonjs，无论创建gemetry的速度还是渲染速度，都快4-5倍左右，内存使用也少1倍以上。原因：babylon相对three属于重量级的引擎了，封装层级太多，提供大量高级api功能，objects套嵌比three多出好几个量级，较为臃肿，内存读取和命中大幅降低
Three.js 使用 WebGPU 需要更改部分核心代码，切换到新的 material 实现，目前不能兼容老的material。babylon保持了几乎完美的api结构，切换WebGPU几乎不需要改变任何代码，能完美兼容旧版的api结构，但Babylon的WebGPU渲染性能实在太差，几乎不可用
Three 和 Babylon 的性能瓶颈，除了渲染性能外，主要在于大量独立 objects 循环进行 matrix 计算，当场景数量大于5k后，CPU损耗时间将无法忽略，fps明显降低，GPU处于等待状态，资源浪费
Three 和 Babylon WebGPU 渲染性能完全没有优势，相比较WebGL，box数量越多，性能反而降低。原因在于：WebGPU没有优化渲染管线，只是简单实现了接口，还是跟webgl渲染管线一致的循环提交buffer 多次darw call的形式，没有按照现代图形管线特性进行优化；尤其是这种大量密集node的场景，WebGPU如果没有利用好group binding进行draw call，性能还不如WebGL
Orillusion 无论在创建时间，内存消耗，渲染帧率等各个方面都有压倒性优势，主要原因：
- ECS架构，没有冗余的Object属性套嵌和层级封装，扁平化组合，提高内存命中和利用率
- 使用Data-Oriented数据结构设计，能充分利用CPU循环命中内存，大幅提升js计算速度，尤其是针对3D场景的大量matrix计算，有明显提升
- 得益于ECS和DO的特性，可以充分利用web多线程能力，使得复杂计算可以并行执行，对 matrix计算再次提升性能
- 充分调用WebGPU的管线特性，将buffer写入/同步和管线渲染分离，尽可能减少CPU和GPU的数据同步次数，减少GPU等待时间
- 充分利用WebGPU bindgroup 的特性，能将objects充分组合提交，尽可能减少drawcall次数，从而大幅提高渲染性能
- Chrome 目前 WebGPU 相关 API 还没有优化完成，尤其是 writeBuffer 和 mapAsync 的性能没有完全发挥，是目前 WebGPU 主要的性能瓶颈。

ukiasu

能搞一个比较新的平台的测试吗？我用12代i9+3070ti的笔记本看了一下demo感觉极限突破了很多，拉到100wbox还有18fps。想看光追性能、PBR材质渲染性能的测试

shuangliu

@ukiasu 现在chrome里还不支持动态选择集成显卡或独立显卡，如果没有手动设置chrome使用3070ti，大概率还是用的i9自带的集成显卡在运行，可以检查一下到底用的哪个gpu

另外，这个webgpu测试中最占据时间的步骤是cpu拷贝数据到gpu，目前的版本这部分的优化还不如webgl的效率，可以去测试一下 webgl和webgpu拷贝数据的效率 https://forum.orillusion.com/topic/39/chrome-writebuffer-performance
如果 Dawn/Chrome 优化的好，理论上应该帧率能提升1倍以上

另一点，目前webgpu还不支持硬件级别的光追管线，如果拿纯软件模拟，渲染效率会比较低，实际的意义不大，这部分可能要等webgpu下一个标准去支持

ukiasu

@shuangliu 谢谢大佬回复，本子开了性能模式核显全局禁用了是在用3070ti跑的，但从占用率看很奇怪cpu和gpu都没跑满，cpu跑的稍微多一点30%占用频率4.3Ghz，gpu占用没上过20%，功耗也都是40w上下，感觉主要还是卡在chrome优化上光追现在只能纯模拟那确实还是玩具，等新标准支持了