Orillusion

    • 注册
    • 登录
    • 搜索
    • 版块
    • 最新
    • 标签

    Chrome writeBuffer Performance

    General Discussion
    webgpu performance writebuffer
    3
    8
    460
    正在加载更多帖子
    • 从旧到新
    • 从新到旧
    • 最多赞同
    回复
    • 在新帖中回复
    登录后回复
    此主题已被删除。只有拥有主题管理权限的用户可以查看。
    • shuangliu
      shuangliu 最后由 shuangliu 编辑

      A simple data performance test between WebGL.bufferSubData and WebGPU.writeBuffer, try to simulate 1million transform matrix submit to GPU:


      For my platform:
      CPU: Intel i7 8700k
      Mem: 16gb
      GPU: Intel UHD 630
      OS: Mac os 12.01
      Chrome: 100.0.4862.3
      Firefox: 99.0a1


      for > 500k, take 1000k for heavy test

      Chrome 100 FireFox 99
      WebGL ~13 ms 26-30 ms
      writeBuffer 50~70 ms 26-30 ms
      mapAsync/unmap 40-50 ms 70-100 ms

      It is obviously that writeBuffer on Chrome is not ready for big dataset, basically 5-10x times slower than bufferSubData. Where mapAsync slightly faster than writeBuffer

      But for <150k, writeBuffer is faster

      Chrome 100 FireFox 99
      WebGL 2 - 4 ms 5 - 6 ms
      writeBuffer 1 - 2 ms ~2 ms
      mapAsync/unmap 5 -10 ms 60 - 100 ms

      For small dataset, the mapAsync is slower …


      When it comes to real application, WebGPU could get up to 20x slower then WebGL in Chrome, the device queue will be blocked while writing multi textrure/matrix/index/vertex ..

      In our contrast test:
      https://contrast.orillusion.com

      Event though Orillusion gets much better overall FPS than Three instance draw, Orillusion actually takes 10x longer time than Three.js in sending data to gpu. When it comes to 300k boxes, Orillusion takes over 50-70ms on writeBuffer where Three only takes 3-4ms on bufferSubData.

      This performance issue has been discussed for a long time, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1266727&q=writeBuffer&can=2
      But it is still not addressed up to Chrome Canary v101

      For now, the best practice in Chrome, try mapAsync if you are working on very big dataset, but may not get much helpful in real application. Use writeBuffer for simple relatively small data is always a good choice. But overall, they are not fast as WebGL so far


      By the way, in our real practice, mapAsync may not a good choice for heavy rendering interactive Application.
      The async callback/promise can be delayed from 4ms up to 20ms, such as mouse/keyboard/ajax/networking events, or other mapAsync jobs.

      If you are working on a computing job, the delay is acceptable. But for real-time rendering, it can trigger a wired fps sometime, unstable frame change, hard to control from JS side. mapAsync vs writeBuffer is like relatively fast but unstable fps vs relatively slow but stable fps.


      Welcome anyone try the test, and post your result.

      1 条回复 最后回复 回复 引用 1
      • shuangliu
        shuangliu 最后由 shuangliu 编辑

        We also opened an issue on chromium official forum

        https://bugs.chromium.org/p/chromium/issues/detail?id=1298309&q=writeBuffer&can=2

        Welcome to submit your tests or ideas anytime to Chrome

        1 条回复 最后回复 回复 引用 0
        • shuangliu
          shuangliu 最后由 shuangliu 编辑

          Also tested on Chrome v98.0.4758.80 (x86_64)

          Chrome
          WebGL ~15 ms
          writeBuffer 60~70 ms
          mapAsync/unmap 70~80 ms

          The mapAsync is slower than writeBuffer

          1 条回复 最后回复 回复 引用 0
          • S
            shabai517 最后由 shabai517 编辑

            For my platform:
            CPU: Apple M1
            Mem: 16gb
            GPU: Apple M1
            OS: Mac os 12.01
            Chrome: 98.0.4758.80(正式版本) (arm64)

            Battery Only Charging
            WebGL 7~10 ms 7~10 ms
            writeBuffer 28~30 ms 28~30 ms
            mapAsync/unmap 31~32 ms 31~32 ms
            1 条回复 最后回复 回复 引用 0
            • S
              shabai517 最后由 shuangliu 编辑

              For my platform:
              CPU: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
              GPU: Inter(R) UHD Graphics / NVIDIA GeForce RTX 3050 Ti Laptop GPU
              Mem: 16gb
              OS: Win11
              Chrome: 98.0.4758.102(正式版本) (64位)

              Battery Only Charging
              WebGL 27~30 ms 14~20 ms
              writeBuffer 110~120 ms 49~53 ms
              mapAsync/unmap 80~100 ms 50~57 ms

              But only Inter(R) UHD Graphics works for the test, cannot change to RTX device

              1 条回复 最后回复 回复 引用 0
              • 支阿怪
                支阿怪 最后由 编辑

                此回复已被删除!
                1 条回复 最后回复 回复 引用 0
                • 支阿怪
                  支阿怪 最后由 编辑

                  此回复已被删除!
                  1 条回复 最后回复 回复 引用 0
                  • 支阿怪
                    支阿怪 最后由 shuangliu 编辑

                    For my platform:
                    CPU: Intel i5 7200U
                    Mem: 8gb
                    GPU: Intel UHD 620
                    OS: Win10
                    Chrome: 100.0.4896.60(正式版本) (64 位)

                    Chrome
                    WebGL 20~ 70ms
                    writeBuffer 120~130 ms
                    mapAsync/unmap 70~90 ms

                    截图:

                    1f59bacf-8720-4aa4-9de1-e2e2d700d416-image.png

                    92a57132-356f-4632-b8cb-8e32630dbf35-image.png

                    我的平台运行WebGL绘制速度不稳定,也可能是我的电脑配置低影响的,不过通过对比,WebGPU确实比GL慢许多,兴许底层优化不够好么? 看来WebGPU的性能值得优化提升!

                    1 条回复 最后回复 回复 引用 0
                    • First post
                      Last post

                    Recent Post

                    • U

                      @huangbeyond 期待他的webgpu2.0😁

                      • 阅读更多
                    • H

                      您是打算上C++来测试WebGPU吗?

                      • 阅读更多
                    • F

                      @shuangliu 谢谢大佬指点,已经能clone下来了😇

                      • 阅读更多
                    • 首先,只设置 http.proxy 就行

                      其次,请明确本地socks5的端口,不是所有的梯子都用1080/1086/443,每个软件都不一样,不要只是搜了网上的例子就粘过来用,比如,我用的 clash 一般是使用 7890 端口

                      git config --global http.proxy 'socks5://127.0.0.1:7890'

                      刚测试过,可以 clone Dawn 的 repo

                      • 阅读更多
                    • F

                      @shuangliu 我使用如下设置

                      git config --global http.proxy http://127.0.0.1:1080 git config --global http.proxy 'socks5://127.0.0.1:1080' git config --global https.proxy socks5://1270.0.1:1086 git config --global https.proxy socks5://1270.0.1:1080 git config --global https.proxy http://127.0.0.1:443

                      都clone不下来

                      • 阅读更多

                    Copyright © 2022 Orillusion | Contact US