176: Fix command buffer and surface locking order r=grovesNL a=kvark
As with all the other locking problems, we just ensure that the locks are in the same order as the fields are in `Hub` structure. This is to be enforced at compile time with #66Fixes#174
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
165: Document how to run example in readme r=kvark a=rukai
This took me a while to figure out, I'm sure others would find it useful in the readme.
Co-authored-by: Rukai <rubickent@gmail.com>
147: Merge '.rustfmt.toml' into 'rustfmt.toml' r=kvark a=Atul9
171: Handle resize in the triangle example r=kvark a=rukai
Handle window resize in the C triangle example.
This fixes https://github.com/gfx-rs/wgpu/issues/166.
The reason it was failing immediately on my machine, is because my window manager was automatically resizing the window.
If I resize the window reallly fast, I still get a few:
```
[2019-05-13T11:00:23Z ERROR gfx_backend_vulkan] [Validation] [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object: 0x5650f23f2510 (Type = 3) | vkCreateSwapchainKHR() called with imageExtent = (798,615), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (590,498), minImageExtent = (590,498), maxImageExtent = (590,498). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
```
It can be merged as is. (Its certainly an improvement)
But if you know how to fix this last validation error, i would love to add it.
Co-authored-by: Atul Bhosale <atul1bhosale@gmail.com>
Co-authored-by: Rukai <rubickent@gmail.com>
163: Remove Rust wrapper and examples r=kvark a=kvark
Fixes#160Closes#60
Everything specific to Rust API is about to be moved to https://github.com/gfx-rs/wgpu-rs
It would let this project to be a proper mirror of mozilla-central piece, and it would encourage other authors to experiment with different approaches to Rust wrappers (i.e. borrowing versus non-borrowing).
cc @jdashg
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
164: Fix locking order in texture view creation and destruction r=kvark a=kvark
Fixes#161
Essentially, this is another case that would solved by #66. At least we can use the library in the mean time before it's implemented.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
159: Add GPU timeout, fix active submission processing order r=kvark a=kvark
Fixes#156
The timeouts are going to be configurable later down the road.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
154: Move callbacks out of the locking path r=kvark a=kvark
Fixes#152
This change fixes the deadlocks discovered by @rukai . It enforces the following invariants through the code:
1. if we enter Rust code from FFI, we assume nothing is locked. The invariant was previously not true when we unmapped a buffer in a mapping callback.
2. the HUB storages are always locked in the same order. This was not followed in a few places, but still needs to be enforced by #66 later down the road.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
157: Add multithreaded_compute test r=kvark a=rukai
As requested in https://github.com/gfx-rs/wgpu/issues/152 I have opened a PR to add the repro as a test case.
I used [rusty fork](https://github.com/AltSysrq/rusty-fork) to allow setting a timeout.
Rusty fork also runs each test in a separate process.
Open to any suggestions on how to organize tests etc.
I could add https://github.com/gfx-rs/wgpu/issues/156 if you want?
Maybe name the tests by issue number?
If we add a test for every issue, breaking changes would become really annoying :/
Co-authored-by: Rukai <rubickent@gmail.com>
153: Update deps + upgrade examples to rust 2018 r=kvark a=rukai
Things to note:
* I removed the Cargo.lock - I assume it was only accidentally checked in?
* I dont know what `wgpu-remote` is for, so I haven't tested it beyond compiling it.
Co-authored-by: Rukai <rubickent@gmail.com>
151: Assert on swapchain output usage before presenting r=grovesNL a=kvark
Fixes#148
There is no "fix" for the case on our side. The PR brings stronger requirements on the swapchain outputs: they have to be used and submitted before dropped.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
140: Creating buffers with size 0 actually creates them with size 1 r=kvark a=rukai
closes https://github.com/gfx-rs/wgpu/issues/135
One concern I have is if the buffer is uninitialized before the call to `self.data.copy_from_slice(slice);`
If that is the case, my new `fill_from_slice` implementation will leave memory uninitialized when the user tries to create an empty buffer.
Co-authored-by: Rukai <rubickent@gmail.com>
144: Rewrite bindings generation r=grovesNL a=kvark
This PR is shaping wgpu-remote to become distantly usable, introduces an example that tests it on CI.
It also rewrites our binding generation to use `cbindgen.toml` configuration, which goes in line with Gecko use case (even though they are going to have a separate configuration).
The `ClientFactory` is introduced so that we can have multiple clients (say, one page per client) talking to the same server on a dedicated thread within the GPU process.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
