120: prototype of futures for buffer mapping r=grovesNL a=swiftcoder
This is largely in request-for-comment state right now, although it does work.
As written the `GpuFuture` implementation only works with types that are `Copy`, which rules out using a destructor to unmap the buffer. I'm assume it's possible to write a future type that can produce a non-Copy result, but I haven't sufficiently internalised how `Pin` works to see how.
Co-authored-by: Tristam MacDonald <swiftcoder@gmail.com>
127: Use u8 for buffer mapping r=kvark a=Coder-256
cc @kvark @grovesNL
This is a temporary solution for #119, and a follow-up for #126.
Co-authored-by: Jacob Greenfield <jacob@jacobgreenfield.me>
126: Fix generic bounds on buffer mapping r=grovesNL a=kvark
Smaller (and incomplete!) alternative to #119 while it's still discussed.
One missing piece here is alignment. cc @Coder-256
Also, importing `wgpu-core` as just "core" wasn't the best idea 😅 : it collides with the actual `core`.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
115: Handle error case for SwapChain::get_next_texture r=kvark a=antonok-edm
Updates `SwapChain::get_next_texture` to account for https://github.com/gfx-rs/wgpu/pull/369. Otherwise, an invalid `Id` is returned and may cause confusing errors.
Co-authored-by: Anton Lazarev <antonok35@gmail.com>
109: add initial skybox example, ref #93 r=m4b a=m4b
1. doesn't render the images at all
2. mip map stuff needs clarification
3. will update uniform with temporal rotation so we can see the skybox better
Co-authored-by: m4b <m4b.github.com@gmail.com>
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>
