gfx-rs
`ShaderStages::all()` causes validation error when used in WebGPU
Since ShaderStages::all now also includes Taks & Mesh shaders, it causes a validation error when used in a WebGPU environment.
As those were introduced only in wgpu 25, this is effectively a regression since it means that code that worked fine in 24 now breaks on 25 when run on the web!
Need to find a way to make all only mean supported shader stages. Which isn't entirely straight forward 🤔
What exactly is the validation issue and what could cause it? I can’t test WebGPU myself. Which part of validation is failing and what validation do you think is missing in wgpu-core?
Also, I’m surprised this went uncaught for so long.
chrome gives you Wgpu validation error 18446744073709551615: Value 31 is invalid for WGPUShaderStage.
wgpu-core is not validating unsupported (or from pov of WebGPU) invalid shader stages, thus causing unexpected discrepancy here.
Debatable whether wgpu's webgpu impl should just strip down the additional shader stages or whether this is practically just a user error (+ missing validation on wgpu-core)
I think the fundamental question is: are you allowed to mention a stage that cannot be used in a visibility bitmask. Currently I think our answer has been yes. We allow you to mention compute when compute isn't supported by the device. I'm not sure if WebGPU has had to make this decision yet (afaik WebGPU compat still supports compute), so we probably should just make a decision and roll with it. I think I'm of the opinion that it shouldn't be a validation error.
I would propose that the binding/attachment stages that aren’t in the pipeline itself(for graphics, mesh, or compute) should just be dropped at pipeline creation time. This would probably save us from issues like these without removing important existing validation.
To specify further, if the pipeline creation is passed say a mesh shader stage for a compute pipeline, it should simply be ignored.
@SupaMaggie70Incorporated I think you're missunderstanding: wgpu-core does not do any validation on this today. But Chrome does for WebGPU (on this path there's no wgpu-core involved) which is what causing the problem in the first place
@Wumpf You’re right, I made a mistake in typing. I edited my comment to hopefully clarify.