WebGPU loads significantly slower

Feature requests
1

I was wondering why our website is rather slow to launch, often taking multiple seconds until it is responsive. After some investigating, here’s what I found

We’re using the Babylonjs WebGPU backend and are writing our shaders in WGSL.
However, a few of the Babylonjs built-in shaders are currently written in GLSL, and Babylon converts them at runtime.

This means

  1. shipping GLSL shaders
  2. then starting up shaderc/glslc that has been compiled to WASM
  3. turning the GLSL into optimized spirv <== takes over 3 seconds
  4. then starting up some other WASM binary
  5. turning the spirv into WGSL
  6. and only then does the browser get a WGSL shader

I pointed the browser developer tools at a page running in development mode, since that’s what’s affecting our workflow the most. This can also be reproduced by going to the Babylon.js Playground and using the browser’s profiler.

image
image2513×1231 273 KB

Would it be possible to find an alternative strategy? e.g.

  • Precompiling the necessary/most common shaders during a Babylon.js build, instead of always having to take the route through two shader compilers
  • Caching the compiled shaders in the browser’s localStorage/indexedDb, with a sensible eviction strategy
  • Rewriting the most common shaders
4 Likes
2

Yes:) this is a pain. We need to support backward compat so shaders need to be in webgl for now. That being said I’m super open to all good ideas and one that you mentioned and that I like a lot: caching them in local storage.

We also discussed internally about precompiling some shaders but the permutations are so high that it is not doable.

But caching could be a way: it would be expensive only the first time (and we could cache using the engine version so if a new version is used we could wipe the cache)

@sebavan @Evgeni_Popov thoughts?

2 Likes
3

I love the caching idea and I think for targetted scenari only maybe there could be a cache download/share option ? like run the full game once, share the cache so all the useful (current permutations) should be warmed up ?

Not saying this is the way to go, but it might be a nice intermediate workaround ?

2 Likes
4

I think we would also have to factor the TWGSL version in addition to the engine version, in case it would have an impact on the WGSL produced…

2 Likes
5

Agreed!

6

@Evgeni_Popov do you mind creating an issue for 8.0 to capture the idea?

7

It would be nice if the material plugins could also be written in WGSL.

8

Here’s the issue:

@noname0310 It won’t be possible until we switch to WGSL as our main shader language, because we can’t / don’t want to maintain two different shader code base (GLSL and WGSL).

4 Likes
9

If we could transpile WGSL to GLSL or vice versa at build time, it would be possible to support two backends (GLSL, WebGPU) with just one code and there’s no runtime transpilation overheads

And for babylon.js to be more sustainable, it seems important to base it on WGSL rather than converting it from GLSL to WGSL.

Because once a system is built, it’s hard to fundamentally change it for backwards compatibility.

2 Likes
10

As for improving the status quo, there are a few more tricks that we could try out right now

and a potentially more involved thing to experiment with would be using naga. I’m not entirely sure how good Naga’s translation capabilities are though.
Naga should be faster at translating though.

4 Likes