1880601 - [WebGPU] With readback, rendering is not updated on a Babylon.js demo (https://playground.babylonjs.com/#BCU1XR#0)

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebGPU, defect, P2)

Description

[Sotaro Ikeda [:sotaro OOO until July/21]]

Use latest Nightly, by default readback for present is enabled by default.
go to https://playground.babylonjs.com/#BCU1XR#0
From the top right, select "WEBGPU"

The rendering of the demo was not updated.

Comment 1

[Sotaro Ikeda [:sotaro OOO until July/21]]

With latest nightly the problem is addressed for me.

Comment 2

[Mayank Bansal]

I have the Nightly with buildid https://hg.mozilla.org/mozilla-central/rev/f8dd4015fa59fee3a1a74c00cd2393a9578e49f0 . I can still repro this bug and bug 1879694

Comment 3

[Sotaro Ikeda [:sotaro OOO until July/21]]

OK, thank you.

Comment 4

[Mayank Bansal]

Babylon version 5.7.1.1 does not show this bug. But the "Latest" version of babylon (V6.4.3 as of 22Feb2024) does show this behaviour.
Versions of babylon can be toggled from the menu at the top-right.

Comment 5

[Sotaro Ikeda [:sotaro OOO until July/21]]

(In reply to Mayank Bansal from comment #2)

I have the Nightly with buildid https://hg.mozilla.org/mozilla-central/rev/f8dd4015fa59fee3a1a74c00cd2393a9578e49f0 . I can still repro this bug and bug 1879694

Sorry, I forgot to change from WebGL2 to WebGPU.

Comment 6

[Sotaro Ikeda [:sotaro OOO until July/21]]

Attachment: logout with nightly

During loading the site, logout had "Device::create_shader_module error".

Comment 7

[Sotaro Ikeda [:sotaro OOO until July/21]]

:ErichDonGubler, can you comment to comment6?

Comment 8

[Erich Gubler [:ErichDonGubler] (he/him)]

:sotaro: If you examine the shader compilation message emitted at the error level in the console, you'll see:

Shader '' parsing error: expected global item ('struct', 'const', 'var', 'alias', ';', 'fn') or the end of the file, found 'diagnostic'
  ┌─ wgsl:1:1
  │
1 │ diagnostic(off, derivative_uniformity);
  │ ^^^^^^^^^^ expected global item ('struct', 'const', 'var', 'alias', ';', 'fn') or the end of the file

I just filed bug 1882800 to track this particular issue, which is that diagnostic filters are not implemented in naga (which backs WebGPU's shader compilation). It should be possible to remove diagnostic filter statements and, since webgpu-uniformity-analysis is not implemented yet and things otherwise should Just Work™.

I'll see if I can reproduce this issue on modified source. We might want to create our own MRE in order to keep working on this.

Comment 9

[Erich Gubler [:ErichDonGubler] (he/him)]

Passing investigation on to :sotaro.

Comment 10

[Sotaro Ikeda [:sotaro OOO until July/21]]

With the STR, log out also had the following error message. It might be related to Bug 1827116.

---

[ERROR wgpu_core::device::global] Device::create_shader_module error:
Shader '' parsing error: unknown type: 'texture_external'
┌─ wgsl:3:45
│
3 │ @group(0) @binding(1) var videoTexture: texture_external;
│ ^^^^^^^^^^^^^^^^ unknown type

Comment 11

[Sotaro Ikeda [:sotaro OOO until July/21]]

:ErichDonGubler, is there an issue of wgpu for 'texture_external'?

Comment 12

[Erich Gubler [:ErichDonGubler] (he/him)]

:sotaro: There is, and that bug is webgpu-external-textures. However, I don't think that the flickering in the OP of this bug is a blocker, since the 5.71.1 version of the demo works on both readback and non-readback paths?

Comment 13

[Sotaro Ikeda [:sotaro OOO until July/21]]

From Bug 1879694 Comment 11, the flickering did not happen when external texture is not recycled. The rendering was displayed momentarily at first and the rest of the time, the rendering was white. The flickering seemed happen by showing old obsoleted WebGPU contents.

From the above, with "Latest" version of babylon, rendering seemed not updated when creating shader module was failed.

Comment 14

[Sotaro Ikeda [:sotaro OOO until July/21]]

Attachment: patch - Use different external texture for each readback

Comment 15

[Sotaro Ikeda [:sotaro OOO until July/21]]

With Attachment 9391932 [details] [diff], different external texture is used for each readback. With it, the rendering was displayed momentarily at first and the rest of the time, the rendering was white.

It also seemed to say that rendering of WebGPU seemed not updated when creating shader module was failed.

Comment 16

[Sotaro Ikeda [:sotaro OOO until July/21]]

My investigation was completed. Reassign to :ErichDonGubler.

Comment 17

[Sotaro Ikeda [:sotaro OOO until July/21]]

(In reply to Erich Gubler [:ErichDonGubler] from comment #12)

:sotaro: There is, and that bug is webgpu-external-textures. However, I don't think that the flickering in the OP of this bug is a blocker, since the 5.71.1 version of the demo works on both readback and non-readback paths?

Yea, it should not be a blocker of Bug 1843891. It seems like a problem of latest Babylon.
The problem seemed to happen when shader compile failed.

Comment 18

[Sotaro Ikeda [:sotaro OOO until July/21]]

Bug 1885490 is going to add a way to disable RemoteTexture recycling for WebGPU. It could be used to check if obsoleted content caused the flickering.

Comment 19

[Erich Gubler [:ErichDonGubler] (he/him)]

The remaining scope of this issue is: we're not sure why BabylonJS isn't trying to render after shader compilation fails. We believe that some changes to shaders related to bug 1882800 are causing us to reject standards-compliant shaders, which BabylonJS doesn't attempt to recover from. Triaging as a P2, to match bug 1882800.

Un-assigning from myself, since I'm not putting active effort into investigating this, ATM.

Comment 20

[Erich Gubler [:ErichDonGubler] (he/him)]

Now that bug 1882800 is resolved, I'm getting the following issues in the developer console:

• This appears to be bug 1827116:

   Shader '' parsing error: unknown type: 'texture_external'
     ┌─ wgsl:3:45
     │
   3 │     @group(0) @binding(1) var videoTexture: texture_external;
     │                                             ^^^^^^^^^^^^^^^^ unknown type
  

• This appears to be a separate issue, and I don't understand the problem statement yet with it:

   Shader validation error: Function [44] 'computeShadowWithPCSS' is invalid
   	┌─ fragment:696:1
   	│  
   696 │ ╭ fn computeShadowWithPCSS(vPositionFromLight: vec4f,depthMetric: f32,depthTexture: texture_2d<f32>,depthSampler: sampler,shadowTexture: texture_depth_2d,shadowSampler: sampler_comparison,shadowMapSizeInverse: f32,lightSizeUV: f32,darkness: f32,frustumEdgeFalloff: f32,searchTapCount: i32,pcfTapCount: i32,poissonSamplers: array<vec3f,64>)->f32
   697 │ │ {var clipSpace: vec3f=vPositionFromLight.xyz/vPositionFromLight.w;
   698 │ │ var uvDepth: vec3f= vec3f(0.5*clipSpace.xyz+ vec3f(0.5));
   699 │ │ uvDepth.z=getZInClip(clipSpace,uvDepth);
   	· │
   708 │ │ blockerDepth=textureSampleLevel(depthTexture,depthSampler,uvDepth.xy+(lightSizeUV*shadowMapSizeInverse*PoissonSamplers32[i].xy),0).r;
   	│ │              ^^^^^^^^^^^^^^^^^^ naga::Expression [58]
   	· │
   732 │ │ shadow=mix(darkness,1.,shadow);
   733 │ │ return select(computeFallOff(shadow,clipSpace.xy,frustumEdgeFalloff),1.0,exitCondition);
   	│ ╰────────────────────────────────────────────────────────────────────────────────────────^ naga::Function [44]
   	│  
   	= Expression [58] is invalid
   	= Sample level (exact) type [57] has an invalid type
  

  I know that :teoxoy and :jnicol have worked recently with textureSampleLevel's argument typing in Naga, which likely governs this error. Teo and Jamie, do you know what's going on here? I noticed that wgpu#6529 is already being consumed in Nightly, and this issue is still showing up.

Comment 21

[Teodor Tanasoaia [:teoxoy]]

depthTexture: texture_2d<f32>,depthSampler: sampler

The 2nd issue is due to abstract types. The 0 should get converted to a float but it's not.

Comment 22

[Erich Gubler [:ErichDonGubler] (he/him)]

This demo WFM now on macOS and Windows; I think the shader that tries to use external textures is unused in the rendering pipeline for this demo. Since we already have separate tracking for that issue, I think this issue can be closed, now.