34: Basic windowing and presentation r=grovesNL a=kvark
- [x] native swapchain creation
- [x] native use of frames and presentation
- [x] native semaphore waits
- [x] rust wrapping
- [x] working examples
~~I may or may not bite the bullet and update gfx-rs here. Probably not :)~~
## Architecture
There is a bit of complexity here to manage all the synchronization and lifetimes properly. Essentially, presentation is exposed in Vulkan/gfx-rs as a separate hidden queue, so we inevitably run into the territory of using semaphores for synchronization, where previously we could ignore them for workloads on a single queue.
A swapchain has a fixed (at creation) number of frames, each represented by a texture plus view pair. When `get_next_texture` is called we acquire the next image index and return this pair. We wait for the associated fence to make sure the frame is no image used. We then associate a semaphore with this index for image availability.
The texture has extra information to link back to an image of the swapchain (which is `None` for regular textures). Whenever it's used, the command buffer collects that link to be used on submission, where it's just resolved to a semaphore that we wait on actual submission.
Presenting on a swapchain creates a temporary command buffer that we only use for transiting the swapchain image into presentable state. This small submission is useful for establishing a "ready" semaphore as well as a fence (waited in `get_next_image`). The "ready" semaphore is used immediately for native `present` call.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
35: Update to current version of gfx-hal r=kvark a=porky11
I'll also push the transition to rust 2018 and some cleanup soon
Co-authored-by: porky11 <krapohl.f@gmx.de>
32: Improve locking safety for Registry r=grovesNL a=kvark
This isn't ideal: we shouldn't be mutably locking anything for adding/removing objects in `local` path. But at least it makes it safe, for now.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
28: Dependencies/makefile update r=kvark a=grovesNL
- Update gfx and add `unwrap`s for now
- Because we're not actively the allocator yet, disable rendy-memory temporarily (until the latest gfx-hal feature is merged and we can start bumping its commit number)
- Use git dependency for cbindgen until the bitflags changes are ready
- Disable C examples in root Makefile until wgpu.h generation is complete
Co-authored-by: Joshua Groves <josh@joshgroves.com>
27: Resource lifetime tracking r=grovesNL a=kvark
Fixes#26
This change ends up being much more serious and intrusive, but hopefully manage-able. The idea is that the native layer would have explicit deletion calls exposed, but would still guarantee that resources live for as long as they are used by either CPU or GPU. The device, in order to guarantee that, keeps track of resources associated with fences and walks through them for clean up.
Maintaining the actual ref-counts per object up-to-date is one of the most challenging tasks. I choose to use the existing `Stored` structure to host it, so that we are forced to clone the refcounts, and it's difficult to screw up. I still had to provide the "old" semantics under the new name of `WeaklyStored` though, and we should be careful about it.
TODO:
- [ ] review and test
- [x] fix transition API once more, so that command buffers are stitched properly and resources are tracked by the device
- [ ] update the Rust layer, using RAII
- [ ] update the examples
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
25: Proper render pass support r=grovesNL a=kvark
This PR implements the API scheme of https://github.com/gpuweb/gpuweb/pull/102 and caches both render passes and framebuffers properly in the device.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
24: Actually begin render passes r=grovesNL a=kvark
For now, we create the render pass and the frame buffer in place. Of course, we'd need to cache it properly, but this is blocked on W3C discussions on the API side.
With this PR, the Rust example is able to create a texture and run a render pass on it, all without a single Vulkan validation error 🎉
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
