Support diagnostic filters in WGSL (i.e., `diagnostic(…)`)

[ErichDonGubler]

We currently do not support the @diagnostic(…) attribute/diagnostic(…) directive (AKA "diagnostic filters" in the WebGPU spec.). This is a rather complicated subsystem, but it's exciting to have robust management of diagnostics in WGSL a la Rust. An example of how this is used from the spec.:

EXAMPLE: Global diagnostic filter for derivative uniformity

diagnostic(off,derivative_uniformity);
var<private> d: f32;
fn helper() -> vec4<f32> {
  if (d < 0.5) {
    // The derivative_uniformity diagnostic is disabled here
    // by the global diagnostic filter.
    return textureSample(t,s,vec2(0,0));
  } else {
    // The derivative_uniformity diagnostic is set to 'warning' severity.
    @diagnostic(warning,derivative_uniformity) {
      return textureSample(t,s,vec2(0,0));
    }
  }
  return vec4(0.0);
}

Relevant part of the spec.: Diagnostics, section 2.3

An initial implementation of this should include the derivative_uniformity rule, as the only current example of filterable trigger rules that can be managed per the spec.

Parse paths that we need to support to be spec.-compliant:

• [ ] Directive: #6148
• [ ] Attributes placements (pasted from he spec.):
  • [ ] Beginning of a compound statement.
  • [ ] Beginning of a function declaration: #6353
  • [ ] Beginning of an if statement.
  • [ ] Beginning of a switch statement.
  • [ ] Beginning of a switch_body.
  • [ ] Beginning of a loop statement.
  • [ ] Beginning of a while statement.
  • [ ] Beginning of a for statement.
  • [ ] Immediately before the opening brace ('{') of the loop body of a loop, while, or for loop.
  • [ ] Beginning of a continuing_compound_statement.

[ErichDonGubler]

Correspondent Firefox bug: bug 1882800

[jimblandy]

This is blocking some BabylonJS demos.

[Mutefish0]

This is blocking some Three.js demos.

[jimblandy]

I think we may want to scope this issue down to simply supporting the syntax, and including the data in the naga::Module somehow, where uniformity analysis could use it, once it's implemented.

We don't have any warnings in Naga right now. Adding the infrastructure for reporting them and filtering them will be a large project, for something we don't even do yet.

This issue's urgency comes from the fact that we can't parse valid shaders, so I think clearing that specific hurdle will be enough.

[jimblandy]

After discussion this morning, we agreed that this issue would remain as filed, and we'd file separate blocker issues for the sub-issues that we want to address immediately.

[floooh]

I'm also running into this btw (FF's dev console pointed me to this issue)

https://floooh.github.io/sokol-webgpu/

(I'm generating WGSL from SPIRV, and to increase compatibility with existing shaders I need to turn off the uniformity diagnostic)

[ErichDonGubler]

@floooh: Looks like you're using filtering rules in directive position (i.e., diagnostic(…); at the top of the file). That should be resolved with #6148! 😊

[ErichDonGubler]

Ack, sorry, this isn't fully done yet (I shouldn't have closed this). We knocked out filters rules in directives with #6148 (🙌🏻), but there's still a lot of attribute positions left to support.

[floooh]

Btw is there a timeline when the fix is expected to land in Firefox Nightly?

[ErichDonGubler]

@floooh: You can follow along with WGPU updates at webgpu-update-wgpu.

We usually re-vendor every week, but we've had some interruptions during the last couple of weeks that have kept us from landing new changes in Firefox. Hopefully this week! 🤞🏻