1951221 - [webgpu] Demo at https://depth2.vercel.app/ doesnt work in Nightly

Status: RESOLVED FIXED

(Core :: Graphics: WebGPU, defect)

Description

[Mayank Bansal]

Attachment: console-export-2025-3-1_14-51-49.txt

Go to https://depth2.vercel.app/
Let the model load
Move the slider
AR: Nothing happens
ER: Image should have the background removed, like it does in Chrome

Error in console: see attachment

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Jim Blandy :jimb]

Attachment: Guessed reproduction case

Comment 3

[Jim Blandy :jimb]

With the test case I just attached, Naga produces the following error:

Could not parse WGSL:
error: automatic conversions cannot convert elements of `i32` to `u32`
  ┌─ guessed.wgsl:4:3
  │
4 │   a[0] = max(0, row);
  │   ^^^^   ^^^ this expression has type i32
  │   │       
  │   a value with elements of type u32 is required here

This should be fixed by the following upstream pull request:
[naga] Builtin function database, for automatic conversions #6833.

If you're curious:

In the call max(0, row), 0 is AbstractInt and row is u32.

Naga's WGSL front end concretizes all arguments to builtin functions. This is contrary to the standard. The concretization of AbstractInt is i32, so this produces a call max(i32, u32).

Naga's typifier assumes that in any well-typed max call, all arguments have the same type, which is the same as the return type. Thus, it takes the type of max's first argument, i32, to be max's return type.

Naga's verifier then complains that i32 isn't the same as the type of the location in which the assignment stores the value, u32.

The builtin function database should fix this problem, because it removes the non-standard concretization, and changes the typifier to consider the types of as many arguments to a builtin call as necessary to narrow the set of possible overloads to a subset that agrees on the return type.

Presented only with AbstractInt as the first argument type, the new code will see that AbstractInt, AbstractFloat, i32, u32, and f32 are all possible return types, depending on the type of the second argument, and thus the return type of the call has not yet been determined.

It will then use the second argument's type as well to narrow down the set of possible overloads. The only overload that accepts u32 as the second argument is max(u32, u32) -> u32, so the return type of the call must be u32.

Comment 4

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

WFM now!