I’m developing a custom shader that’s quite large (~1300 lines in the fragment code) and the compilation process is very slow (~15 seconds until I get to see any change).
I use ShaderStore to store the shader (I have a separate Typescript file contaning the fragment code in a string and ShaderStore boilerplate code for registration), the vertex shader is very light, the mesh I’m applying the material based on the shader is ~70K triangles, but that should be irrelevant to the shader compilation time, so setup-wise, it’s nothing fancy. I run Babylon.JS v5.25.0.
System-wise, I’m running on a i7-8700K with 64GB of RAM and an RTX 4090.
I tested on Firefox and Chrome, with parallel shader compilation and without - same duration.
I know I should have a PG demonstrating the problem, but in this case I can’t really release any code…
I’m not doing any loops that may trigger unrolling, but I do have about 100+ uniforms and lots of dynamic branching.
My question is what are my options for bringing down the compilation time?
Since my post doesn’t provide actual code, I’m expecting a more conceptual answer, but if you have any practical advices, I’d be very happy to receive them.
What do you mean by “what compiler”? I wrote GLSL code and put it in a string in ShaderStore - pretty standard way of adding a custom shader.
I’m assuming that at run-time (perhaps when creating the material out of the shader), the shader code I wrote gets processed, compiled internally by the engine, uploaded on the GPU and binded to the CPU code. There is no explicit, external compilation involved.
Regarding the upgrade, it’s not really up to me, but I am pushing for it.
Sorry for the noob question but I’m just wondering which part exactly takes 15s.
Is it webpack recompiling the code, or starting the HTML page and scripting part or something else?
Okey, sorry for the noobish question again but is there a way to find out what exactly takes so much time?
I mean in the browser you can record performance and check which function is taking how much time
So if it is starting the page 15s maybe it is possible to check on that.
I’ve also found something like that
Sorry if I’m taking totally nonsense, just trying to be helpful
I hope someone more competent in this area will help you soon
I’ll have a look at Chrome for Devs reference and perhaps pin-point more accurately what takes so much.
The page loads fast, the rest of the meshes and their materials load also fast, but when it gets to my mesh and its material it takes ~15 seconds to make it visible.
It may be FXC that’s taking time (the shader compiler used by Chrome to compile shaders on Windows). You can try switching the graphics backend to “OpenGL” to see if that’s where the problem lies:
In any case, I’m afraid there’s nothing we can do on our side if the problem really is with the browser-side compilation (upgrading to a newer version of Babylon won’t help in this respect).
I switched from Default to OpenGL and now it loads almost instantly.
However, if I deploy the app on mobile and the problem reproduces on client-side, it’s clear I won’t be able to instruct the client to amend the abstraction layer backend. Any suggestions on how I can force that under the hood (perhaps the engine could request a preferred backend)?
Unfortunately you can’t. It’s not a setting we can change programmatically…
Note that you probably won’t have this problem on mobiles, as FXC is specific to Windows. On mobile, the browser is using a different compiler (depending on the OS).
