You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#6833, which improved Naga's WGSL compatibility a lot, costs more in performance than it seems like it should.
Although it's not our priority right now, I was feeling rebellious so I took a few hours to hook up the perf_event crate to Naga and count cycles and instructions spent in the WGSL front end and the validator. (The perf_event crate only works on Linux.) I rebased this on the wgpu trunk commit just before #6833, and then rebased all of trunk on that, so I could select any commit since then and get comparable timings.
Using some large WGSL generated from SPV, the change across landing #6833 was
in the WGSL front end, 15.047M instructions to 16.204M instructions (+7%)
in the validator, 0.775M instructions to 1.828M instructions (+135%)
Note that validation seems to take about 5% as much time as parsing, so the larger percentage change there is less significant. In both cases the absolute change is around 1M instructions, which makes sense: they're both visiting the same set of math operations.
I don't know whether it's reasonable to expect Naga to do more work (computing the right type conversions) without any loss of performance. But it also doesn't seem to me that this should double the cost of validation.
I think most users are willing to pay a certain amount for standards conformance. The question is whether it is really necessary, or whether a different design - say, letting OverloadSet take all the argument types simultaneously, and choosing a different way to report errors - would let us have our cake and eat it too.
#6833, which improved Naga's WGSL compatibility a lot, costs more in performance than it seems like it should.
Although it's not our priority right now, I was feeling rebellious so I took a few hours to hook up the
perf_event
crate to Naga and count cycles and instructions spent in the WGSL front end and the validator. (Theperf_event
crate only works on Linux.) I rebased this on the wgpu trunk commit just before #6833, and then rebased all of trunk on that, so I could select any commit since then and get comparable timings.Using some large WGSL generated from SPV, the change across landing #6833 was
Note that validation seems to take about 5% as much time as parsing, so the larger percentage change there is less significant. In both cases the absolute change is around 1M instructions, which makes sense: they're both visiting the same set of math operations.
I don't know whether it's reasonable to expect Naga to do more work (computing the right type conversions) without any loss of performance. But it also doesn't seem to me that this should double the cost of validation.
I think most users are willing to pay a certain amount for standards conformance. The question is whether it is really necessary, or whether a different design - say, letting
OverloadSet
take all the argument types simultaneously, and choosing a different way to report errors - would let us have our cake and eat it too.I've pushed my instrumented Naga
trunk
here: https://github.com/jimblandy/wgpu/tree/perf-trunkIf you simply run the
naga
CLI, it will log counts:The text was updated successfully, but these errors were encountered: