WebGPU: fix crashes in Firefox and Safari

[Popov72]

This PG crashes in Firefox / Safari because an empty vertex buffer is bound to the pipeline. The fix is simply to call this._createOffsetsBuffer() earlier so that the correct vertex buffer is created (cc @RolandCsibrei, to make sure it's the right fix / in the right place).

This PG crashes for the same reason, but the fix is a bit more complex as we shouldn't use an attribute in a node material if the mesh using that material doesn't support the attribute. So I've added some code to declare a regular (dummy) variable with the same name as the attribute when the latter is not supported.

Note that I also added some debug code (mostly labels) to ease debugging in WebGPU.

[bjsplat]

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

[bjsplat]

Snapshot stored with reference name:
refs/pull/16045/merge

Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16045/merge/index.html

To test a playground add it to the URL, for example:

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16045/merge/index.html#WGZLGJ#4600

Links to test babylon tools with this snapshot:

https://playground.babylonjs.com/?snapshot=refs/pull/16045/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/16045/merge
https://gui.babylonjs.com/?snapshot=refs/pull/16045/merge
https://nme.babylonjs.com/?snapshot=refs/pull/16045/merge

To test the snapshot in the playground with a playground ID add it after the snapshot query string:

https://playground.babylonjs.com/?snapshot=refs/pull/16045/merge#BCU1XR#0

[bjsplat]

Visualization tests for WebGPU (Experimental)

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16045/merge/testResults/webgpuplaywright/index.html

[bjsplat]

WebGL2 visualization test reporter:

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16045/merge/testResults/webgl2playwright/index.html

[RolandCsibrei]

Unfortunatelly the changes in GRL has introduced an error on WebGL in Safari/Firefox/Chrome - I'm on MacOS:
[.WebGL-0x128005cf100] GL_INVALID_OPERATION: Vertex buffer is not big enough for the draw call
and doesn't create any output in Safari with the WebGPU flag enabled. It does work with Chrome WebGPU, though.

I tried to get WebGPU support working in Firefox by enabling the required flags, but no luck.

Let me do some research.

[Popov72]

Ah, too bad... It could be that the offsets buffer is not yet set when calling _createOffsetsBuffer from updateLazy.

One question I have is if offsets are always used, or if they are optional? The shader code always define the grl_offsets attribute, but if offsets are optional, the attribute shouldn't be defined, as we won't be able to pass vertex data for it. Instead, for minimal changes, you should replace the attribute declaration with a dummy variable declaration, something like:

#ifdef GREASED_LINE_USE_OFFSETS
    attribute vec3 grl_offsets;
#else
    vec3 grl_offsets = vec3(0.);
#endif

Of course, you will have to set the appropriate true/false value to GREASED_LINE_USE_OFFSETS depending on offsets usage.

[RolandCsibrei]

I think we have two options:

1. Add a define to the material plugin and set it when the offsets are set. This will recompile the shader.
2. Create the offsets vertex buffer when creating the line and fill it with vec3f(0.0). This will not require shader recompilation.

Which is the better choice?

Interestengly the PG runs w/o issues on Chrome/WebGPU.

[Popov72]

I think 1/ would be better, because it would not consume a vertex buffer when we don't need it.

The PG runs in Chrome because they don't handle a limit condition the same way than in Firefox/Safari, but the specification allows both implementations.

[RolandCsibrei]

I think 1/ would be better, because it would not consume a vertex buffer when we don't need it.

Yes, this seems to be the better option. I don't expect anyone to frequently set or unset the offsets, so there will essentially be one shader recompilation when the offsets are initially set. Changing the offsets afterward will not require shader recompilation.

I'm on it... Thanks for sharing your thoughts!