Naga shouldn't evaluate overrides unless they're used by the entry point #5885
Comments
jimblandy
added
type: bug
|
Firefox downstream tracking: bug 1953930 |
|
This is P1 for Firefox because it prevents this WebGPU Sample from running: https://webgpu.github.io/webgpu-samples/?sample=samplerParameters |
Changes the MSL and HLSL backends to support writing only a single entry point, and uses them that way in wgpu-hal. This is working towards a fix for gfx-rs#5885.
Changes the MSL and HLSL backends to support writing only a single entry point, and uses them that way in wgpu-hal. This is working towards a fix for gfx-rs#5885.
Changes the MSL and HLSL backends to support writing only a single entry point, and uses them that way in wgpu-hal. This is working towards a fix for #5885. * Increase the limit in test_stack_size
|
Yesterday @andyleiserson and I talked about this. #7652 follows an approach that I'd suggested, and while his implementation of the idea was reasonable, the strategy wasn't playing out in a very encouraging way. In particular, it seemed to require spot checks in a lot of different places; if you have to check something in five places, there's sure to be a sixth that you've forgotten, and a seventh you'll add by mistake. Andy had originally suggested that compaction could be adapted to simply remove everything from the module not needed by the selected entry point, including functions. This would let us leave the existing override evaluation pretty much unchanged. At the time I was concerned about the performance impact of using compaction in this way, but after seeing the code in #7652, I'm coming around to the merits of an approach that allows backends to remain innocent, and be concerned simply with generating code for the module they're given. So the strategy we're planning to pursue at the moment is:
|
When generating code for a
naga::Module, Naga currently evaluates every override-expression it can, regardless of whether that expression is statically used by the entry point(s) for which we are generating code. The WGSL committee's recent discussions clarified that errors should only be reported from override-expressions that are actually statically used.The text was updated successfully, but these errors were encountered: