Size of fully vendored `gpu-allocator` with `"d3d12"` is quite large

Firefox would very much like to use gpu-allocator in its Direct3D12 backend for WebGPU on Windows, but we cannot:

• Firefox has a policy of vendoring all our dependency crates into the source tree, to meet security requirements.

• Firefox currently has a policy of not accepting the windows as a dependency, despite it being the officially supported bindings crate for Windows APIs, because of its size when the unpacked crate sources are vendored. As large as the Firefox sources already are, vendoring windows into the tree would be a notable increase. (However, Firefox does permit depending on the windows-sys crate.)

As a result, Firefox's WebGPU implementation uses wgpu's Direct3D12 backend without enabling the windows-rs feature, meaning that we use an older, slower path that does not suballocate buffers. We'd like to put this behind us and begin using gpu-allocator to do things right.

Right now, running cargo vendor in a crate that simply depends on gpu-allocator with the "d3d12" feature enabled produces a 238MiB vendor subdirectory.

Is there any way that gpu-allocator could reduce the size of its vendored footprint?

• Could we use windows-bindgen at build time to generate only the bindings we need?

• Are the old winapi bindings close enough to those from windows-rs that gpu-allocator could have some optional configuration that went back to depending on winapi, using the macros to generate whatever bindings are missing?

Those are just two strategies that occur to me, but any tactic to avoid bringing in windows-rs will serve.

Mozilla is willing to do the work. We're just looking for a plan that would be acceptable for inclusion in this code base; forking would be a waste of time and attention in all the generally-understood ways.

Thanks very much for considering our situation!

Background and prior discussion

#107 goes into the reasons gpu-allocator migrated to windows-rs - a move that makes perfect sense.

gfx-rs/wgpu#3207 is the wgpu issue covering this question.

cc: @erichdongubler

Start by reading issue #107 and the linked wgpu#3207 discussion to understand the migration rationale and current constraints. Compare the proposed windows-bindgen and winapi approaches against the vendored footprint described here. Done means an agreed, maintainable plan for reducing the d3d12 dependency size that is acceptable for inclusion in gpu-allocator.