Remove odd patching matching
Replace std::sync::Mutex with spin::Mutex in GpuFuture
Reduce GpuFuture usage to one explicit allocation instead of two
Fix examples to poll the device in the background when using map_read or map_write
Remove device.poll from GpuFuture::poll and document future invariants
Massively simplify examples
Use Arc::clone(...) instead of arc.clone()
Switch println to log::info
213: Cleanup user-interface around async buffer mapping r=grovesNL a=lachlansneff
This PR cleans up the interface for asynchronous buffer mapping a little. It turns `map_read` and `map_write` into `async` functions (instead of returning `impl Future<...>`). It also adds a standin error type and removes some confusing type aliases.
Co-authored-by: Lachlan Sneff <lachlan.sneff@gmail.com>
219: Update Zerocopy to 0.3 r=kvark a=cwfitzgerald
In an effort to eliminate duplicate dependencies, especially on the proc-macro/syn stack, this updates zerocopy 0.2 (using syn 0.6) to zerocopy 0.3 (using syn 1). There appears to be no real api changes based on my skimming of the docs. Things compile on my windows machine, and hopefully it will pass on mac and linux.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
210: Update WGPU deps to rev 08e8d406c1 r=kvark a=aloucks
I also moved the `path` chunks in `Cargo.toml` to a single `[patch]` section so that it's one block to commment/uncomment for local development.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
212: Improve BufferCopyView documentation r=kvark a=rukai
groves suggested that the alignment/multiple requirements are not implemented yet.
So I changed the documentation to reflect that.
Ideally we would change the examples to demonstrate how to work around this requirement, but I think its best to wait until we know for certain that this IS a requirement, currently the WebGPU spec does not have this as a requirement.
Additionally it seems like every example except for the skybox example failed to follow this part of the WebGPU spec.
"Note: rowsPerImage must be zero for copies with a copySize.depth of 1, and must be greater than zero otherwise."
So I fixed those examples and documented the requirement on the field.
Co-authored-by: Rukai <rubickent@gmail.com>
208: Remove lifetime from SwapChainOutput r=kvark a=lachlansneff
The pr removes the lifetime from `SwapChainOutput`. It's not clear to me if the lifetime is necessary for soundness reasons, so let me know if so.
Resolves#207
Co-authored-by: Lachlan Sneff <lachlan.sneff@gmail.com>
204: Return futures from request adapter/request device r=kvark a=grovesNL
Relevant to #175
Backporting some parts of #193 for async request adapter and async request device.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
202: Remove `Hash` for ID types r=kvark a=grovesNL
Reverts some of the `Hash` derives added in #200 because we don't have a good way to support `Hash` for JavaScript objects (for the web backend) at the moment. JavaScript objects don't have a unique identifier that we can use for `Hash`, so any solution here would probably mean adding our own map of JS object<->unique ID.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
200: Derive `Hash` and `PartialEq` for unique identifier wrapper types r=kvark a=mitchmindtree
This is particularly useful downstream for distinguishing between
instances of these types.
I was unsure about `Device` as I noticed it has a `Temp` field that
looks like it might eventually store some non-PartialEq/Hash-friendly
fields.
Let me know if you'd like me to add a derive for `Device` or if there
are any issues with those I have updated.
Co-authored-by: mitchmindtree <mitchell.nordine@gmail.com>
201: Add note that `slot` refers to the index in RenderPipelineDescriptor r=kvark a=aloucks
Add note that `slot` refers to the index in `RenderPipelineDescriptor::vertex_buffers`
Also fixed intra-doc links for `set_vertex_buffer`.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
This is particularly useful downstream for distinguishing between
instances of these types.
I was unsure about `Device` as I noticed it has a `Temp` field that
looks like it might eventually store some non-PartialEq/Hash-friendly
fields.
Let me know if you'd like me to add a derive for `Device` or if there
are any issues with those I have updated.
192: Explicitly declare vertex attribute descriptors in cube example r=kvark a=aloucks
The new `vertex_attr_array!` macro is pretty wonderful, but it's nice to have at least one reference example of how `VertexAttributeDescriptor`s are constructed.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
189: Reexport Backend and DeviceType from wgpu-core r=kvark a=aloucks
These types are exposed on the `AdaptorInfo` struct.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
185: Update readme r=kvark a=grovesNL
Add logo and update readme text a bit (link to WASM progress, reword examples section slightly, etc.)
[Rendered](ea4bf79ff7/README.md)
Co-authored-by: Joshua Groves <josh@joshgroves.com>
184: added test to hello-compute example r=kvark a=emmetthebarnraiser
I wasn't exactly sure of the proper way to test async stuff, but this is a strategy that seemed to work for me. Let me know if there is anything you would like me to change, or if this isn't something that you would like to add to the examples!
Co-authored-by: Brian Frazho <befrazho@gmail.com>
183: Expose `enumerate_adapters`. r=kvark a=daxpedda
Depends on gfx-rs/wgpu#505.
Use case was to give end user the ability to choose which GPU to use for an application.
Co-authored-by: daxpedda <daxpedda@gmail.com>
179: Add vertex_attr_array macro r=kvark a=dhardy
Specifying `VertexAttributeDescriptor` arrays is tedious, and for no good reason. This PR adds a macro to do the job.
All examples tested. Documentation is short but better than the standard for this crate I feel. 😉
Co-authored-by: Diggory Hardy <git@dhardy.name>
169: Disable window bitmap redirection r=kvark a=kvark
That sets `WS_EX_NOREDIRECTIONBITMAP`. According to @raphlinus, makes our resize better :)
There are still strange pauses I see on resizing with DX12 (with and without the change), to be followed-up.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
