98: Add pixels to the friends list r=kvark a=parasyte
We're using `wgpu` to create the world's most powerful pixel frame buffer. 😂
The crate isn't published yet. Waiting for `wgpu` 0.4: https://github.com/parasyte/pixels/issues/16
Co-authored-by: Jay Oster <jay@kodewerx.org>
92: Fix docs describing how to create a surface r=grovesNL a=parasyte
I noticed this issue as I was combing the source.
Co-authored-by: Jay Oster <jay@kodewerx.org>
89: Adapter::get_info r=kvark a=paulkernfeld
This more or less addresses #7.
If the example is too trivial, I'm happy to remove it.
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
87: Add indirect draw/dispatch methods r=kvark a=swiftcoder
It looks like the indirect draw/dispatch methods are present in wgpu-native, but not yet exposed in the wrapper.
Co-authored-by: Tristam MacDonald <swiftcoder@gmail.com>
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>
