408: Handle adapter enumeration failures better r=kvark a=kvark
Fixes#406
It appears that the target system could support Vulkan but is misconfigured.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
394: Get buffer sub data in wgpu-remote r=kvark a=kvark
Required for `mapReadAsync` implementation in Gecko.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
387: Stop dynamic offset iteration when the bind groups stop r=grovesNL a=kvark
Fixes#386
I imagine the code is not performance-optimal and could be improved. This PR focuses on correctness.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
385: Fix build for iOS r=kvark a=grenlight
```
Compiling wgpu-native v0.4.0 (https://github.com/gfx-rs/wgpu?rev=b51053dc2dc3bbe9b2ba050fde42eeb6405fe092#b51053dc)
error[E0422]: cannot find struct, variant or union type `Surface` in this scope
--> /Users/LiJinlei/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/b51053d/wgpu-native/src/device.rs:24:24
|
24 | Rwh::IOS(h) => Surface {
| ^^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
```
Co-authored-by: LiJinlei <grenlight@icloud.com>
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>