Glslang csp issue

Questions
1

Running the glslang library requires unsafe-eval in my csp in order to work. Unfortunately, that is unacceptable for me. I understand this lib is not maintained by bjs, who should I elevate this issue with ? KhronosGroup ?

Also, I’ve ported my shaders to wgsl, do I still need the external libs? Is there a way to completely remove these dependencies when initializing the engine?

2

cc @BabylonNative

3

I’m not sure this is a native question. I think we are talking about WebGPU usage in Babylon.js? @phaselock Can you confirm?

4

Yep, not native related. Sorry for ambiguous post. I followed the steps in doc to setup my webgpu engine. Copied the glslang and twgsl files to local directory. Upon running my app, console in chrome refused to load glslang due to missing csp flag unsafe-eval. Everything worked when I added in unsafe-eval. But unsafe-eval is not an acceptable for my use case.

5

My two cents (until @Evgeni_Popov will be able to answer correctly) -

the wasm dependencies are not compiled by us, so they might be using unsafe eval internally, which we can’t control. If the unsafe eval is in the framework itself (something we control) we can fix it for sure. Can you see what exactly triggers it?

If it is glslang then - yes, the Khronos group would be the right address. It might have also already been addressed in a newer version than what we use.

EDIT - looking at the glslang repo, there are newer versions, and they only provide the source code, so it might have been compiled by @Evgeni_Popov? If that’s the case, we might be able to control this, but i’ll wait for his answer to be sure.

1 Like
6

Glslang is now lazy loaded, so if all shaders are already in WGSL, it shouldn’t be used => our goal is that Babylon doesn’t need glslang / twgsl anymore, and have them used only in case users write custom glslang code.

Maybe we missed to port some of our shaders from GLSL to WGSL. Can you set engine.dbgShowShaderCode = true and look at the output in the console log? All shader code will be dumped, it may help to find which shader is not ported yet. You can also share a link, if possible.

1 Like
7

I think its on my end as per (updateFloatArray vs webgpu) post. Ran into the issue while adding the wgsl, set it aside, finished the rest and tried starting the webgpu engine (thinking it was all done). Will have to wait for the next release to confirm…

I see the huge dump in console from dbgShowShaderCode, what should I be looking for? Eyeballing, it seems everything is in wgsl. Do I have to export and dig thru? I have shaders still not in wgsl yet but since they are not loaded at startup, there should be no impact?

For the record, csp errors (sniped) are below. I’m not sure what stance to take on this, best to defer to the core team. But users should know what they are getting if bjs is supplying the libs from cdn…

wasm streaming compile failed: CompileError: WebAssembly.instantiateStreaming(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
Uncaught (in promise) RuntimeError: abort(CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
8

if no glsl is loaded then glslang should not be loaded at all. If we have a repro somewhere we can investigate but the overall idea for you is to breakpoint when the glslang is loaded and go up the call stack to detect which shader needs it

The line you want to break on:
Babylon.js/packages/dev/core/src/Engines/webgpuEngine.ts at 181ecc755dd3629feed08a560077b02947e74c7b · BabylonJS/Babylon.js

2 Likes
9

If possible, i would say that we still need to see if we are able to compile glslang without the unsafe-eval, if anyone will ever need it in the future. But that’s just a side-note and probably not 100% related to this thread

2 Likes
10

It may not be easy to go up the stack from there, because we are already in a promise at that point. Setting a breaking here should be better in this regard:

1 Like
11

Found it, 4 occurences of #define SHADER_NAME fragment:minmaxRedux while starting up Seedborn on dev.

What I did was to edit my local npm js file as below:

if (shaderLanguage === 0 /* ShaderLanguage.GLSL */ && !this._glslangAndTintAreFullyLoaded) {
    console.log(fragmentSourceCode)
    await this.prepareGlslangAndTintAsync();
}
12

If I had like say, 100 glsl shaders, which is the easier choice? huge wgsl rewrite or a 3mb download auto conversion? There WILL be users who will grab it.

And its still related, security is stiff for regulatory practices. I could get fined (5 figures sum minimum) if it got live and a white hat auditor caught it when I did not.

1 Like
13

This PR will fix the problem with the min/max redux shader not being ported to WGSL:

2 Likes