Size of fully vendored `gpu-allocator` with `"d3d12"` is quite large
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 20/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- rust
调研方向
首先阅读 issue #107 以及链接的 wgpu#3207 讨论，以了解迁移的理由和当前限制。将提议的 windows-bindgen 和 winapi 方案与此处描述的 vendored footprint 进行比较。当形成一个经一致同意且可维护的计划，以减少 d3d12 依赖的大小，并且该计划可接受纳入 gpu-allocator 时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
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
windowsas 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, vendoringwindowsinto the tree would be a notable increase. (However, Firefox does permit depending on thewindows-syscrate.)
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-bindgenat build time to generate only the bindings we need? -
Are the old
winapibindings close enough to those fromwindows-rsthatgpu-allocatorcould have some optional configuration that went back to depending onwinapi, 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
- 主要语言
- Rust
- 星标
- 503
- 派生
- 87
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Traverse-Research/gpu-allocator 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
Traverse-Research/gpu-allocator#286 · 1 个 reaction ·
-
难度 2/5 1-3 小时 新手友好度 68/100
Traverse-Research/gpu-allocator#103 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 52/100
Traverse-Research/gpu-allocator#313 · 2 条评论 · 1 个 reaction ·
-
难度 5/5 一周以上 新手友好度 25/100
-
难度 3/5 1-2 天 新手友好度 65/100
查看 Traverse-Research/gpu-allocator 的全部 Issue
相似的 Issue
-
bug priority: low ui
难度 2/5 1-3 小时 新手友好度 65/100
storytold/photocraft#10370 · 1 条评论 ·
维护者通常 1 天内回复
-
area:doc bug in progress needs-triage
难度 2/5 1-3 小时 新手友好度 72/100
bherbruck/solvecraft#9634 · 2 条评论 · 1 个 reaction ·
-
inflate: total_in uses plain += on c_ulong (32-bit on Windows), panics in debug for streams > 4 GiB未关闭
难度 1/5 1 小时以内 新手友好度 85/100
trifectatechfoundation/zlib-rs#570 · 1 条评论 ·
-
bug discord-triage
难度 2/5 1-3 小时 新手友好度 84/100
LanternOps/breeze#10755 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
aranya-project/aranya#803 ·