3 ms·

GPU profiling for WebGPU workloads on Windows with Chrome

71 points by ibobev 2y ago

pjmlp 2y ago
It is a sad state of affairs that after so much Web 3D push for the last 15 years, Khronos advocacy of how great it is and we should all be rushing out to use them, browser vendors keep ignoring the need of proper developer tooling for 3D applications. The best we have is either SpectorJS (showing its age, WebGL only), trying to differentiate between app calls and browser calls in a native GPU debugger, or create an alternative, completly unrelated native version, to sanely use a GPU debugger.
- deleted 2y ago
  [deleted]
- _factor 2y ago
  I think the bigger issue is security. GPU access is too interlinked to kernel drivers. I’ve seen WebGPU and even WebGL crash otherwise stable systems.
  - pjmlp 2y ago
    Yeah, however having a debugging tool, that developers have to explicitly open in developer tools, for debugging shaders and drivers that are always used by the browser anyway, doesn't change that.
    - stanleykm 2y ago
      Agreed. Chrome already has flags to reduce the security posture for developers. It is not outrageous to expect you’d need to use those for profiling gpu shaders. This is a huge gap in the browser gpu ecosystem, especially since wgsl is missing features (like unrolling hints) that can result in dramatically different performance vs hlsl or whatever.
  - tw061023 2y ago
    WebGPU is supposed to be properly sandboxed. The bigger issue is that WebGPU is basically dead on arrival for the same reasons WebGL is - it is impossible to get enough data to the client for it to actually matter, Awwwards-style design tricks notwithstanding. I suppose browser vendors understand this and don't really care for either.
    - nmfisher 2y ago
      What do you think could fix this? Access to genuinely permanent storage?
      - tw061023 2y ago
        That's one part of it, yes. A browser API providing a few GBs of persistent storage with proper isolation and user management, obviously with some kind of compression/decompression going on to save both download times and loading times. As an example, consider Infinity Blade, the poster child of mobile gaming: released in 2010, 595 MB download, 948 MB installed. Even the first version of WebGL is capable of providing this kind of experience, we just cannot get it to the user via browser.
        pjmlp 2y ago
        I found out another fellow soul, that is exactly one of my complaints with Web 3D, the failure to 15 years later to provide the same experience as Infinity Blade, used by Apple to show off iPhone's OpenGL ES 3.0 capabilities. Or Unreal Engine Citadel demo, originally done in Flash / C++.
        deleted 2y ago
        [deleted]
    - ossobuco 2y ago
      That may be true (for now) for web apps, but what if you serve your app/game as a desktop app, for example with tauri?
    - 2y ago
ossobuco 2y ago
I've been using the webgpu inspector extension[0] and so far it's proving very useful. There are some occasional bugs but the author is very responsive on github and quick to fix issues. Couldn't get anything useful out of PIX on the other hand. - [0]: https://github.com/brendan-duncan/webgpu_inspector https://github.com/brendan-duncan/webgpu_inspector
- Twinklebear 2y ago
  I’ve been able to profile using PIX following this guide: https://toji.dev/webgpu-profiling/pix https://toji.dev/webgpu-profiling/pix . The WebGPU inspector extension is fantastic as well
ingen0s 2y ago
dll go brrrr
kvark 2y ago
Back when I worked on WebGPU in Firefox, GPU debugging was pretty straightforward. You’d use a setting that enables API traces of WebGPU, give it a path, and it would produce a trace. Then you’d replay it in a standalone application that is easily ran from NSight/RenderDoc/PIX/whatever. Moreover, you could replay it on a different platform with a different API! It was a breeze. I bet it still works. http://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-api-tracing.html http://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-a...

71 points by ibobev 2y ago

It is a sad state of affairs that after so much Web 3D push for the last 15 years, Khronos advocacy of how great it is and we should all be rushing out to use them, browser vendors keep ignoring the need of proper developer tooling for 3D applications. The best we have is either SpectorJS (showing its age, WebGL only), trying to differentiate between app calls and browser calls in a native GPU debugger, or create an alternative, completly unrelated native version, to sanely use a GPU debugger.

deleted 2y ago
[deleted]
_factor 2y ago
I think the bigger issue is security. GPU access is too interlinked to kernel drivers. I’ve seen WebGPU and even WebGL crash otherwise stable systems.
- pjmlp 2y ago
  Yeah, however having a debugging tool, that developers have to explicitly open in developer tools, for debugging shaders and drivers that are always used by the browser anyway, doesn't change that.
  - stanleykm 2y ago
    Agreed. Chrome already has flags to reduce the security posture for developers. It is not outrageous to expect you’d need to use those for profiling gpu shaders. This is a huge gap in the browser gpu ecosystem, especially since wgsl is missing features (like unrolling hints) that can result in dramatically different performance vs hlsl or whatever.
- tw061023 2y ago
  WebGPU is supposed to be properly sandboxed. The bigger issue is that WebGPU is basically dead on arrival for the same reasons WebGL is - it is impossible to get enough data to the client for it to actually matter, Awwwards-style design tricks notwithstanding. I suppose browser vendors understand this and don't really care for either.
  - nmfisher 2y ago
    What do you think could fix this? Access to genuinely permanent storage?
    - tw061023 2y ago
      That's one part of it, yes. A browser API providing a few GBs of persistent storage with proper isolation and user management, obviously with some kind of compression/decompression going on to save both download times and loading times. As an example, consider Infinity Blade, the poster child of mobile gaming: released in 2010, 595 MB download, 948 MB installed. Even the first version of WebGL is capable of providing this kind of experience, we just cannot get it to the user via browser.
      - pjmlp 2y ago
        I found out another fellow soul, that is exactly one of my complaints with Web 3D, the failure to 15 years later to provide the same experience as Infinity Blade, used by Apple to show off iPhone's OpenGL ES 3.0 capabilities. Or Unreal Engine Citadel demo, originally done in Flash / C++.
        deleted 2y ago
        [deleted]
  - ossobuco 2y ago
    That may be true (for now) for web apps, but what if you serve your app/game as a desktop app, for example with tauri?
  - 2y ago

ossobuco 2y ago

I've been using the webgpu inspector extension[0] and so far it's proving very useful. There are some occasional bugs but the author is very responsive on github and quick to fix issues. Couldn't get anything useful out of PIX on the other hand. - [0]: https://github.com/brendan-duncan/webgpu_inspector https://github.com/brendan-duncan/webgpu_inspector

Twinklebear 2y ago
I’ve been able to profile using PIX following this guide: https://toji.dev/webgpu-profiling/pix https://toji.dev/webgpu-profiling/pix . The WebGPU inspector extension is fantastic as well

ingen0s 2y ago

dll go brrrr

kvark 2y ago

Back when I worked on WebGPU in Firefox, GPU debugging was pretty straightforward. You’d use a setting that enables API traces of WebGPU, give it a path, and it would produce a trace. Then you’d replay it in a standalone application that is easily ran from NSight/RenderDoc/PIX/whatever. Moreover, you could replay it on a different platform with a different API! It was a breeze. I bet it still works. http://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-api-tracing.html http://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-a...