Allow configuring whether workgroup memory is zero initialised #5508
Conversation
There was a problem hiding this comment.
It's not great that we're adding this field that needs to be set in every pipeline descriptor anyone will ever write. But I understand that Vello wants to be a good neighbor when sharing Devices with other code, so we can't make it a device-wide flag.
Could we see an alternative version of this PR where the flag is on wgpu_core::pipeline::ShaderModuleDescriptor, rather than ComputePipelineDescriptor?
Do you mean as a seperate PR, or reusing this same one? |
|
It's worth noting we don't have the Are the shaders in question surpassing those limits? |
|
Using a loop to do array initialization might also side-step the issue (if it doesn't get unrolled that is). |
|
As it happens, we are exactly on the limit for |
|
Yes, as I say, fixing #4592 would also likely resolve this issue, as it would cause us to output probably ~24 instructions rather than 16384 But this is much easier to implement, and the actual zero initialisation is superfluous work anyway Besides which, wgpu would still use the native zero initialisation method on Vulkan Android, which would mean we would still need to disable it. The native method is at least faster than the polyfill. But it would be slower if #4592 reaches the same result |
|
Moving into draft whilst I reconfigure as requested |
|
This now shares the breaking change with #5500, using the mechanism discussed on Matrix. So it is a breaking change, but the "same" breaking change was already needed from. CC @teoxoy , as you brought in the I'm now quite happy with how this API looks - it also removes the need for everyone to set |
This is a performance improvement for shader compilation. See gfx-rs/wgpu#5508
This is a performance improvement for shader compilation. See gfx-rs/wgpu#5508 --------- Co-authored-by: Lixou <82600264+DasLixou@users.noreply.github.com>
Connections
This is related to #5319 - a key reason initialisation takes so long is the 5x increase in pipeline creation time added by this feature
See also #4592, which this does not fix.
I'm planning on racing this PR with a fix for #4592, in the hope that I can get one of them in 0.20
(Both PRs should be useful, however.)
Description
Allows skipping zero initialisation of pipeline workgroup variables.
Backends:
The underlying pipeline creation time issue is a really significant issue for adoption of Vello and Xilem, as it makes our projects take an extremely long time to start up.
This decreases pipeline creation time by a factor of (nearly) 5 on Android, which makes this a worthwhile tradeoff for us.
Renderer creation time with different modes (all values in millseconds).
Nonecorresponds to the newZeroInitializeWorkgroupMemory::never(). This is on a Pixel 6This is a breaking change, but this breaking change is shared with #5500
Testing
I have tested the improperly wired up version of this in Vello, to get the above numbers.
I have also tested this PR in Vello, which showed the expected decrease in startup time
Checklist
cargo fmt.cargo clippy. If applicable, add:--target wasm32-unknown-unknown--target wasm32-unknown-emscriptencargo xtask testto run tests - same story as Pipeline cache API and implementation for Vulkan #5319 - no new failuresCHANGELOG.md. See simple instructions inside file.