69: Swapchain resize r=kvark a=kvark
Based on #67
Here are the steps (as outlined on Gitter) that this PR follows:
1. create a dummy frame in the swapchain (`SwapChain::outdated`). We return it when we aren't able to acquire a real frame. No synchronization is done atm, but shouldn't be anything critical there.
2. handle the errors on acquire and present, use the dummy frame where needed. Presentation errors are just ignored, while acquiring errors are forcing the dummy frame. The idea is that the user would know about a swapchain resize from some kind of event loop / WSI, and thus they'd know when they should actually re-create it.
3. associate surface with a swapchain. We merge the IDs since there can't be multiple swapchains on the same surface in the near future. Merging simplifies a lot of things in the implementation, but this is to be revised for sure once we get a better look on the browser integration.
4. when the swapchain is re-created, consume the old one associated with a surface.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
70: Allow creating a surface by passing a metal layer. r=kvark a=seivan
This is useful if you're using `SDL2`
```rust
let canvas = window.into_canvas().build().unwrap();
let metal_layer = unsafe { sdl2::sys::SDL_RenderGetMetalLayer(canvas.raw()) };
let surface = instance.create_surface_with_metal_layer(metal_layer);
```
For now, Metal only - but could be useful in the future if there was a trait or a facade to use for setting up a surface. The intention is to support other window backends without depending on them directly as a dependency.
Co-authored-by: Seivan Heidari <seivan.heidari@icloud.com>
This is useful if you're using `SDL2`
```rust
let canvas = window.into_canvas().build().unwrap();
let metal_layer = unsafe { sdl2::sys::SDL_RenderGetMetalLayer(canvas.raw()) };
let surface = instance.create_surface_with_metal_layer(metal_layer);
```
62: Separate object identity from storage r=grovesNL a=kvark
This turned out to be a giant change touching multiple parts... with main goal to prepare for wgpu-remote. The basic incompatibility I found is that the client side needs to know the IDs and manage them, while the server side needs to access the actual objects by those IDs. This change moves the `IdentityManager` out, while still making it convenient for the local bindings to use it the old way.
The actions for creating a buffer remotely would be:
1. client allocates a new ID
2. client sends the descriptor and ID to the server
3. server creates an actual backend object from the descriptor
4. server associates it with the given ID
While doing that, I also decided to bring the local/remote registries closer together. There isn't much benefit from representing an ID with a pointer in local mode. Locking is still the same (at least, it's hugely problematic to make it different and maintain both paths sanely), and the cache utilization is better when they are stored sequentially. This simplification leaded to the renaming and refactoring of "registry/mod.rs" to just "hub.rs".
Total list of changes:
- separate object identity from storage, this affects all the entry points creating items. They are now split into a public-visible "_impl()" method that just creates something, and the old creation is only visible under "local" feature now, using that helper. The sequence of actions on remote is different, as described above.
- unified local/remote registries
- "local" feature instead of "remote"
- removed blend and depth/stencil interfaces in favor of structs inside the pipeline descriptors
- pipeline descriptors are update to reflect the IDL (shader stages, rasterization state, color states, etc)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
54: Document how to run examples r=grovesNL a=rukai
I had assumed the triangle example wasn't functional yet, because I didn't realize I had to specify a feature. I only realized it was supposed to work when I saw a screenshot of the cube example.
I'm not sure what the future is of the triangle example? Will it remain outside of the gfx-examples folder?
Co-authored-by: Rukai <rubickent@gmail.com>
56: Initial compute pipeline support r=kvark a=swiftcoder
Hey, I'd love to help out with this effort, but please let me know if I'm only going to be slowing you down :)
Sample is a port of https://github.com/gfx-rs/gfx/blob/master/examples/compute/main.rs - as yet incomplete because we don't have a read-back API defined.
I'm happy to do the implementation of the read-back API, but I wanted to touch base about how you envision `mapReadAsync`/`mapWriteAsync` working in Rust. Do we introduce futures to match the webgpu spec? Or expose it in a more direct fashion.
Co-authored-by: Tristam MacDonald <swiftcoder@gmail.com>
53: Depenency gfx update to 0.1.1 r=almost_simple a=kvark
It appears that we still can't run on DX12, because it has `update_buffer` as `unimplemented!`. But at least we have the benefit of the empty backend updates.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
52: Gfx examples framework r=grovesNL a=kvark
Fixes#37
It's not functional yet, I think it needs a proper resize event handler. We can do this incrementally.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
51: native: basic support for pipeine stages in barriers r=grovesNL a=kvark
It's a naive approach focused on solving the Vulkan validation errors :)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
48: Set buffer data r=grovesNL a=kvark
Simple and limited implementation, should be sufficient for the first examples.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
