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>
23: State transitions for a render pass r=grovesNL a=kvark
This PR introduces a simple resource tracker, which is used to build the pipeline barriers gluing the main command buffer with the one composed for the render pass contents. Render passes are still not started properly, blocked on the W3C discussion about the parameters.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
21: Use pointers for descriptors r=kvark a=grovesNL
(Mostly) fixes#20
I didn't try to handle the remote case yet, but it will need serialization as we mentioned.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
