-
Notifications
You must be signed in to change notification settings - Fork 329
Closed
Labels
apiWebGPU APIWebGPU APIcompatWebGPU Compatibility ModeWebGPU Compatibility Modepotentially breakingCould require a breaking change to the APICould require a breaking change to the APIwgslWebGPU Shading Language IssuesWebGPU Shading Language Issueswgsl resolvedResolved - waiting for a change to the WGSL specificationResolved - waiting for a change to the WGSL specification
Milestone
Description
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?
Metadata
Metadata
Assignees
Labels
apiWebGPU APIWebGPU APIcompatWebGPU Compatibility ModeWebGPU Compatibility Modepotentially breakingCould require a breaking change to the APICould require a breaking change to the APIwgslWebGPU Shading Language IssuesWebGPU Shading Language Issueswgsl resolvedResolved - waiting for a change to the WGSL specificationResolved - waiting for a change to the WGSL specification