83: Propagate making Vulkan backend available to wgpu-rs r=kvark a=yanchith
`wgpu-native` has `gfx-backend-vulkan` feature which makes Vulkan available on macOS. This adds the feature to `wgpu-rs` also.
Co-authored-by: yanchith <yanchi.toth@gmail.com>
82: Return Queue separately r=grovesNL a=kvark
What problem is this PR trying to solve? We want `Device` to be freely accessible from multiple threads/objects and internally synchronized. `Arc<Device>` seems like a natural choice of such a sharable object, especially since all except one methods are `&self`.
That one method is `get_queue()`, and it returns a temporary object `Queue<'a>`. If we turn it into `&self`, we'd end up with multiple instances of `Queue` created at any time, which contradicts the initial design (of this Rust wrapper). If it stays `&mut` and the user wraps the device into `Arc`, they'll never be able to submit any work...
So this PR solves this by moving the `Queue` completely outside of the device.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
73: Update wgpu-native to the commit that has no backend features. r=grovesNL a=kvark
This change removes the dependency on gfx-rs backends, refactors
Adapter and Surface creation to be done from nothing.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
71: Use `HasRawWindowHandle` in `create_surface` r=kvark a=hecrj
This change lets users use `wgpu` without listing `raw-window-handle` as a direct dependency themselves.
Co-authored-by: Héctor Ramón Jiménez <hector0193@gmail.com>
70: Wholesome update for wgpu-0.3 r=everyone a=kvark
~~This update is a little more opinionated, i.e. the BGL creation just accepts a slice of things instead of a descriptor. I believe the reason for descriptors in the upstream API is mostly techincal - it's more convenient to generate bindings in Googles giant codegen. Following it verbatim doesn't appear to be strictly necessary, especially if we can extract better usability from Rust features.~~
The change also disables "gl" feature for the release. We'll re-enable it once we can provide it nicely, it will not be a breaking change.
I also noticed that barriers are not working correctly on the mipmap example. Will investigate separately - the native part is already published anyway. Edit: fixed by https://github.com/gfx-rs/wgpu/pull/302
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
69: Prevent possible double panic in Drop impls r=kvark a=yanchith
Drop impls for `SwapChainOutput`, `RenderPass` and `ComputePass` now only
call out to `wgn` if not `thread::panicking()`.
Fixes#50
Co-authored-by: yanchith <yanchi.toth@gmail.com>
67: Update to latest wgpu-native commit r=kvark a=rukai
closes https://github.com/gfx-rs/wgpu-rs/issues/66
Make sure my documentation for sample_mask and alpha_to_coverage_enabled is correct, I am not familiar with these fields.
Co-authored-by: Rukai <rubickent@gmail.com>
61: Cleanup examples by using wgpu::read_spirv instead of manually creating a Vec<u32> r=kvark a=rukai
Wait for me to update the git reference once https://github.com/gfx-rs/wgpu/pull/280 is merged.
Co-authored-by: Rukai <rubickent@gmail.com>
38: Add an example showing how to capture a render r=kvark a=paulkernfeld
I had wanted to use wgpu-rs to generate `.png` images rather than displaying to the screen, so I coded up this prototype as an example to others who might want to do something similar.
Possible changes:
- Create an actual `.png` or other image
- Convert this into a unit test
I'm happy to make other modifications to this as well.
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
40: Update running an example documentation r=kvark a=Napokue
- Removed link to gfx getting started
- Created our own getting started (with examples)
- Updated syntax
Motivation: I always forget how to run the examples, gfx getting started is not the same as the wgpu-rs one. So I found the correct usage of the syntax to run examples. I am noticing in the Gitter channel that many people are struggling with running the examples, maybe this will clear it up a little.
This is the beginning, I will continue to expand the documentation in the future.
Co-authored-by: Timo de Kort <dekort.timo@gmail.com>
