WebGL: INVALID_ENUM: getProgramParameter: invalid parameter name

Questions
1

EDIT: Solved but leaving in case others have the same issue!

Hi!

I’ve come across and error which I’m having trouble debugging:

WebGL: INVALID_ENUM: getProgramParameter: invalid parameter name
    await in _processShaderCodeAsync

It’s being thrown from scene.render() in

engine.runRenderLoop(() => {
    scene.render();
});

It happens when trying to play a GLTF animation with a skybox in the scene, or when adding a skybox while an animation is playing - specifically when this code is present:

engine.getCaps().parallelShaderCompile = false;
[... load environment texture to scene ...]
engine.getCaps().parallelShaderCompile = true;

I disable it while the environment is loading in to prevent a flash while the shaders compile, so I don’t really want to remove that. And it’s then enabled again 500ms after the environment’s loaded.

What I especially don’t understand is how that also affects trying to play/stop animations afterwards - even once it’s been reset to true :thinking:

Why might this be happening? Any ideas?

2

Ah - I worked it out. It seems that even though there’s a few different dicussions on the forums talking about setting engine.getCaps().parallelShaderCompile to true or false, it actually needs a KHRParallelShaderCompile object (which I can’t find documented anywhere unfortunately).
So my solution was to do:

let parallelShaderCompile = engine.getCaps().parallelShaderCompile;
engine.getCaps().parallelShaderCompile = null;
[...]
engine.getCaps().parallelShaderCompile = parallelShaderCompile;

I presume there must be a way to create a new KHRParallelShaderCompile object, but I can’t find where to import that from :sweat_smile:

3

@leo_h it means we probably miss some kinds of checks within babylon following some of our latest refactoring.

Could you provide a repro so we can fix it and you do not need to disable parallel shader compilation ?

1 Like
4

Which part exactly to you want repro’d?

Disabling parallelShaderCompile is necessary as otherwise there’s a flash of black on complex meshes while shaders take a moment on slower hardware to compile for the first time when adding a skybox to a scene (after having already loaded + interacted with the scene - so can’t be hidden behind the initial load screen) - my assumption is that this is expected behaviour?

The error meanwhile seems to have been due to in that process of disabling parallelShaderCompile while the environment loads in, I was setting it to false and then afterwards true, as this is how I’ve seen it used by a few people here on the forums and there’s seemingly not really very clear documentation for it. This caused some kind of issue with animations that were already playing or that were started afterwards, throwing the error and preventing animations from working. Using this instead of true/false fixed it:

let parallelShaderCompile = engine.getCaps().parallelShaderCompile;
engine.getCaps().parallelShaderCompile = null;
[...]
engine.getCaps().parallelShaderCompile = parallelShaderCompile;

So if this is how parallelShaderCompile is intended to be used then as far as I can tell the only actual issue seems to be that as there’s very little documentation about it then quite a few of the past forums discussions that come up are incorrectly (?) setting it to true/false, and the little documentation there is doesn’t explain much, not mentioning the KHRParallelShaderCompile object or what values COMPLETION_STATUS_KHR can take :sweat_smile:
image
If it’s not meant to be used with true/false then presumably the error isn’t relevant as the property is being used wrong?

5

Understood, thanks a lot for the explanation, I thought the system by default was emitting the error without any changes so that it would seem the framework would not wait correctly for shader compilation completion

1 Like