-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring d3d12
crate in-tree
#3987
Bring d3d12
crate in-tree
#3987
Conversation
1: Initialize crate r=kvark a=msiglreith The crate is supposed to be a Rust wrapper around D3D12. Motivated by trying to hide the FFI behind a nicer to use layer (part of BAL). It aims at providing a zero-cost abstraction without any overhead at all (no transition costs between Rust structs and D3D12 structs or allocations). The API closely ressambles the d3d12 interfaces and is strucutered accordingly. It currently uses a custom `ComPtr` implementation which does not do any refcounting, therefore requires manual destruction when dropping. Co-authored-by: msiglreith <m.siglreith@gmail.com>
`D3D12_HEAP_TYPE, D3D12_CPU_PAGE_PROPERTY, D3D12_MEMORY_POOL, D3D12_HEAP_FLAGS, D3D12_HEAP_PROPERTIES, and D3D12_HEAP_DESC ID3D12Heap Wrap ID3D12Device::CreateHeap Made a tricky enum because DX12 doesn't follow Rust's rules bump version to 0.2.0 Use bitflags for heap::Flags Fix typo Another typo fix
9: Add structs and enums for ID3D12Heap r=msiglreith a=DethRaid I've added the structs and enums needed to create an `ID3D12Heap`. I've also added the method `create_heap` to `Device`, and and added the module imports and reexports to the appropriate places The weird thing here is `heap::Flags`. Thing is, D3D12 uses the value 0 for two of the enum constants in `D3D12_HEAP_FLAGS`. Rust does not allow the same value to be used by multiple enum constants (that I know of). I made an enum without any useful values, then gave it constants with the values from `D3D12_HEAP_FLAGS`. This lets my code compile, and the syntax to use the enum is the same, but the compiler complains about capitalization and I don't really like it. I'd welcome any ideas about a better way to implement this Co-authored-by: David Dubois <dexcelstraun7@gmail.com>
I think we should split this change - one MR to bring in exactly what we depended on previously. Then follow up MRs to improve/iterate on the apis. |
This comment was marked as duplicate.
This comment was marked as duplicate.
I will plan on changing this PR to “just” bring 0.7 (or a fixed |
This comment was marked as outdated.
This comment was marked as outdated.
I think we should leave d3d12 completely untouched from the commit we were depending on. That way we can land the organizational change without testing on Firefox, and reducing the pressure to land all of the subsequent changes |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
9cf23d7
to
dabe457
Compare
Addressed feedback by "just" using the Crates.io commit for 0.7.0 (which, notably, is not the same as the v0.7.0
tag in gfx-rs/d3d12
).
dabe457
to
d16c7fc
Compare
d3d12
crate in-treed3d12
crate in-tree (squashed)
d16c7fc
to
b3a4ed6
Compare
d3d12
crate in-tree (squashed)d3d12
crate in-tree
8878689
to
9e2d73d
Compare
I've noted in Matrix chat that
d3d12
, as a crate, sits in an awkward place. It does not realize the potential it was apparently envisioned to have of being a robust abstraction that others can use, like withmetal
orash
. It remains totally coupled to WGPU's needs. And yet,d3d12
also reaps no benefits of its coupling. Many D3D12 APIs used WGPU's D3D backends are bound only inwgpu-hal
, which defeats the purpose of having a dedicated layer for D3D12 interop. For those APIs that are captured by thed3d12
crate, effective development requires two compilation feedback loops across repositories.The crate barrier also inhibits Clippy andrustc
lints that would surely be useful for code that could otherwise be a module tree inwgpu-hal
.@cwfitzgerald noted that he'd be open to inlining
d3d12
code intowgpu-hal
. I also took time to get some Mozilla consensus; @jimblandy laughed in apparent catharsis when I declared thatd3d12
is, proverbially, a child who either needs to get a job and pay its rent, or move back in with its parents (i.e.,wgpu-hal
). So, here's the PR making moving the entirety of thed3d12
crate from there to here!This PR copies the subtree-merges
d3d12
repo into a newd3d12
top-level folder.It also fixes up some integration issues that appear unique to the currentHEAD
of thed3d12
repo.Note that while this is inlining
d3d12
for now, there's no reason that we can't or shouldn't eventually try to grow the in-tree crate into a well-formed separate repository again. No plans for that are established here, but it's a definite future possibility.I've taken pains to ensure that actual changes to code are easy to distinguish as small commits, while keeping mechanical movement of code to larger ones. Therefore, recommended review experience is by commit.Post-merge checklist:
d3d12
crate?Checklist
cargo clippy
.cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
Link to the issues addressed by this PR, or dependent PRs in other repositories
Linked in prose above.
Description
Describe what problem this is solving, and how it's solved.
See my prose above.
Testing
Explain how this change is tested.
No behavior should change because of this PR. I consider successful compilation to be a sufficient test for it.