Compat: WGSL validation at createShaderModule or createPipeline time?

[Greggman]

Currently, the compat proposal validates most WGSL restrictions at pipeline creation time. A validation error is only generated if the entry points used by the pipeline use one of the unsupported features.

Example:

const module = device.createShaderModule({ code: `
  @vertex fn codeThatUsesTextureLoadWithDepth() {
    ...
  }
  
  @vertex fn codeThatDoesNotUseTextureLoadWithDepth() {
    ...
  }
  `,
});
  
device.createRenderPipleine({
  vertex: {
    module,
    entryPoint: compatibilityMode
       ? 'codeThatDoesNotUseTextureLoadWithDepth'
       : 'codeThatUsesTextureLoadWithDepth',
  },
  ...

This has the benefit that you can easily put shared code in the same module string and choose at runtime which entryPoint to use.

On the other hand, WGSL has chosen that unsupported or un-enabled features generate errors at shader module creation time. This has the advantage that errors have line/column numbers which is more informative.

Should the compat recommendation switch to errors at shader creation time? Stay at pipeline creation time? Do something else?

[Greggman]

Examples of the WGSL features to be validated out

• use of @builtin(sample_mask) and @builtin(sample_index)
• use of linear and sample with @interpolate(...)
• calling textureLoad with texture_depth_???
• calling textureSampleLevel or textureSampleLevelCompare with texture_depth_2d_array

[Greggman]

Another interesting related issue is, compat does not support cube arrays but texture_cube_array<T> is not validated out, at least not according the current proposal.

Instead, creating a texture view texture.createView('cube-array') is validated out so it's impossible to use a pipeline that requires a cube array.

If it's decided to validate out the other WGSL features at shader module creation time this should probably be validated out too. If the others stay as a pipeline creation error I suspect this one will need to add a pipeline creation error too since there's nothing valid to translate the WGSL into GLSL.

[Greggman]

Can this be on the WGSL agenda? Compat is stalled until this is resolved.

[dan sinclair]

This was discussed at the last meeting: https://docs.google.com/document/d/1vaICnZrSK_3xexJhJsMGkj_vtie2WHnav1gADmEP-88/edit#bookmark=id.gbgc1udsz1hm

The relevant part being: KG: Sound like consensus that the cautious path is to make it an error at shader creation time. We can revisit as needed.

• (DS: Generally errors are generated as soon as possible. But currently Dawn is validating compat rules only at pipeline creation time. But these oppose each other. If all the compat info is available at shader-creation time, then should those be shader-creation errors.)

• (MW: Lean checking more things at shader-creation time, but will take a look.)

• JB: Mozilla tended to want to make it a module-creation -time error. It’s more consistent, and easier to plumb the diagnostics through (if you want good diagnostics). It’s an advantage to have alternate code paths for the two cases and select compat vs. non-compat at pipeline-creation time. But that’s a lean.

• KN: I’m in favour of them being consistent, but I’m concerned we’ll want to solve the problem in general, so it will be easier to pick up optional features.

• KG: If we want to delay the error to pipeline time, we can add that to the shading language spec. There’s some backward compat risk if we later move these validations to pipeline creation time.

• KN: If we want to move errors to pipeline creation time, then all syntax for all the features need to be parseable by all browsers. So you can read entry points but ignore as needed.

• JB: We’re in an unusual situation; we’re starting it with a complete thing but export it to implement a subset. So having to parse everything is not a problem; the implementation already does.

• KN: Right, it’s an issue for future optional features. But it would be nice to be consistent.

• DS: If we add int64, then you have to parse some new suffix for int64 literals. How do you handle that.

• KN: Generalize the grammar, e.g. allowing any letter suffix to numbers.

• JB: The more we talk about applying this to other features the more uncomfortable I become with delaying errors to pipeline creation. The more we talk about this as a general solution I want to make it error at shader-creation time.

• MW: I have similar concerns.

• KN: We can revisit this later. As far as implementation, try to make it easier to change in the future.

• KG: Sound like consensus that the cautious path is to make it an error at shader creation time. We can revisit as needed.

[Kelsey Gilbert]

WGSL 2024-04-30 Minutes

• (DS: Generally errors are generated as soon as possible. But currently Dawn is validating compat rules only at pipeline creation time. But these oppose each other. If all the compat info is available at shader-creation time, then should those be shader-creation errors.)
• (MW: Lean checking more things at shader-creation time, but will take a look.)
• JB: Mozilla tended to want to make it a module-creation -time error. It’s more consistent, and easier to plumb the diagnostics through (if you want good diagnostics). It’s an advantage to have alternate code paths for the two cases and select compat vs. non-compat at pipeline-creation time. But that’s a lean.
• KN: I’m in favour of them being consistent, but I’m concerned we’ll want to solve the problem in general, so it will be easier to pick up optional features.
• KG: If we want to delay the error to pipeline time, we can add that to the shading language spec. There’s some backward compat risk if we later move these validations to pipeline creation time.
• KN: If we want to move errors to pipeline creation time, then all syntax for all the features need to be parseable by all browsers. So you can read entry points but ignore as needed.
• JB: We’re in an unusual situation; we’re starting it with a complete thing but export it to implement a subset. So having to parse everything is not a problem; the implementation already does.
• KN: Right, it’s an issue for future optional features. But it would be nice to be consistent.
• DS: If we add int64, then you have to parse some new suffix for int64 literals. How do you handle that.
• KN: Generalize the grammar, e.g. allowing any letter suffix to numbers.
• JB: The more we talk about applying this to other features the more uncomfortable I become with delaying errors to pipeline creation. The more we talk about this as a general solution I want to make it error at shader-creation time.
• MW: I have similar concerns.
• KN: We can revisit this later. As far as implementation, try to make it easier to change in the future.
• KG: Sound like consensus that the cautious path is to make it an error at shader creation time. We can revisit as needed.