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>
49: GLFW integration r=grovesNL a=kvark
This is #40 that is rebased and fixed a bit.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
45: Remove non-winit from the example r=grovesNL a=kvark
This are the follow-up fixes to #38 as suggested by the review
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
42: Remove glfw submodule r=nobody a=grovesNL
Fixes#41
I temporarily added a glfw submodule as part of #40 but it looks like it was mistakenly added as part of #39
Co-authored-by: Joshua Groves <josh@joshgroves.com>
39: Remove generic and option from render pass descriptor r=kvark a=grovesNL
- Temporarily lock cbindgen to known working revision until a new version is published
- Remove generic and `Option` from `RenderPassDescriptor`, map between wgpu/wgpu-native types like other descriptors, and add a missing length field (this appears necessary to generate bindings)
- Regenerate bindings (using `a7be40c65 2018-12-26`, earlier versions should work too)
- Remove `+nightly` for bindings generation from Makefile, because newer nightlies won't work at the moment
- Fix typo in Makefile `clean`
Co-authored-by: Joshua Groves <josh@joshgroves.com>
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>
