427: Rewrite of the resource lifetime tracking r=crossed-fingers a=kvark
Addresses this TODO item in `triage_referenced()`:
> //TODO: lock less, if possible
Now, also fixes#428
Pros:
- only locking the storages that need to be, and only for the duration of their cleanup
- less run-time branching, more predefined code paths, which may lead to better cache utilization (thinking of both instruction and data cache here)
- more consistent use of `Stored` type
Cons:
- a bit of verbosity / code duplication in `triage_referenced()`. In particular, the code that finds where to register an unreferenced resource, it used to be unified for all resources.
---
@grovesNL this should be reviewable on a commit basis. The high-level breakdown of changes is:
1. Switch from enum of resource types to structure of arrays for the matter of lifetime tracker
2. Rename the involved structures to better reflect what they do (the old `PendingResources` was bad)
3. Separate lifetime tracking into a sub-module
4. Make `RefCount` in objects optional, getting the semantics of "user needs it" when `Some`.
5. Rewrite the first stage of lifetime tracking: instead of permanently staging resources that the user doesn't need, and adding strong refcounts to them, we only populate it temporarily with anything that gets the refcount reduced. This means less overhead for `maintain()` at an increased risk of leaking some stuff (depends on our code quality).
6. Consequently, device tracker becomes the main (and last) owner of all the resources.
Overall, it's a major change and risk. I tested on `vange-rs` (which I consider to be the most complex wgpu-rs app) with Vulkan validation enabled, and it seems all to be working good now.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
442: Fix cmd buffer cleanup not always using lowest active index r=kvark a=LaylConway
This fixes the index picked for cleanup not always being the lowest index.
Additionally this fixes command buffers not being cleaned up if there are no active submissions, because in that case 0 would be picked, which resulted in nothing being cleaned up. Now instead if there are no active submissions, usize MAX will be picked.
Fixes#441
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
431: Expose FFI for creating wayland surface on wgpu-native r=kvark a=segfault87
* Added `wgpu_create_surface_from_wayland()` for creating Wayland surface from C side.
* Updated FFI header and `examples/triangle` example accordingly.
Co-authored-by: Park Joon-Kyu <segfault87@gmail.com>
429: Defer command buffer recycling until allocate r=kvark a=LaylConway
As discussed on Matrix, this change defers command buffer recycling until allocation.
This lets a rendering thread clean up its own command buffers, making sure only the owning thread accesses anything from its command pool.
I have also added a TODO comment about cleaning up thread pools, which currently isn't happening as far as I can tell. This previously was an issue as well but now is a slightly bigger one as the command buffer wouldn't get recycled either.
I figured that, for now, fixing that issue is out of the scope of this PR. This PR focuses only on resolving the race condition causing the validation error.
This fixes#423
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
418: Hotfix deadlocks on resource cleanup r=kvark a=LaylConway
This resolves resource cleanup causing deadlocks with `maintain`, because of `Device::pending` being locked in reverse order.
I'm calling this a "hotfix" because I don't think this is a scaleable approach to resolve how the issue happened in the first place, but it alleviates current deadlocking isssues.
I'm not quite sure how `Token` works, so I don't know if I used that right here.
This fixes#417
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
412: Another big tracking refactor r=later a=kvark
Fixes#409
Note: there is way more code that had to be thrown out in the process of this PR than there is in the PR itself.
Also fixes [this comment](04e17b3f4f/wgpu-core/src/track/texture.rs (L29)):
> //TODO: make this less awkward!
## Logic
Instead of having a run-time per-operation control over what state is being used for stitching (with `Stitch` enum), we are now deriving this automatically on a per-subresource level. Whenever we are detecting a transition for a sub-resource, and we know there wasn't any "first" state associated with it in the current tracker, we are saving this "first" state. Unlike previous code, where it was confusing what of `Unit` fields (`init`, `last`) are valid, now `first` is `Option<>`, so we know we should be using it if it's there.
This allows us to have this hybrid tracking state of a render pass, where all resources are immutable (and their usage is extended), except for the output attachments. This, together with a whole lot of refactoring, gets us #409.
I'm actually quite happy with the tracking code now. It's finally taking shape we aren't afraid to tell others about :)
Note: this was tested on wgpu-rs examples and vange-rs.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
416: Makefile package command and travis github releases r=kvark a=Korijn
Closes#414
Approach mostly mimicked from [gfx-portability](https://github.com/gfx-rs/portability) as recommended to me by @kvark. I needed a number of commits to iron out some kinks for the Windows builds, so I would recommend using squash merge when accepting this PR.
Note that the Windows rust=nightly build fails, but it's also broken on master, so it's unrelated to the changes in this PR.
/cc @almarklein
# Questions
- [x] Would it make sense to also regenerate the `ffi/wgpu.h` and `wgpu-remote.h` header files and include them in the zip archive?
# Todo for maintainers
- [x] Configure encrypted `api_key`
As in [gfx-portability](https://github.com/gfx-rs/portability/blob/master/.travis.yml#L61) you will need to create an API key and commit it to the `.travis.yml` file. I've checked "allow edits from maintainers" so you should be able to commit to this branch directly. You may want to reference the [Travis instructions](https://docs.travis-ci.com/user/deployment/releases/#authenticating-with-an-oauth-token) as well.
- [ ] Tag revisions
Previous versions (`v0.1` - `v0.4`) have not been tagged on the master branch, you will want to do so retroactively. Also, when releasing in the future, make sure to tag the commit before pushing. Alternatively, you can schedule a travis build manually after applying the tag retroactively.
420: Make Origin3d::{x,y,z} all have type u32 r=kvark a=fintelia
Fixes#419
424: swapchain creation: check if selected present mode is supported r=kvark a=Veykril
Implements a simple check as talked about in #350 to fallback to `FIFO` should the selected present mode not be available on the system.
Co-authored-by: Korijn van Golen <k.vangolen@clinicalgraphics.com>
Co-authored-by: Korijn van Golen <korijn@gmail.com>
Co-authored-by: Jonathan Behrens <fintelia@gmail.com>
Co-authored-by: Veykril <lukastw97@gmail.com>
426: configure rust msvc toolchain on windows on travis r=kvark a=Korijn
Closes#425
@LaylConway's [proposal](https://github.com/gfx-rs/wgpu/issues/425#issuecomment-569737145) was right.
Apparently Travis configures the non-standard GNU toolchain on Windows by default; it's unclear why and kind of defeats the point of Windows CI for this project, so we reconfigure it to use the MSVC toolchain manually in the `before_install` stage.
/cc @kvark
Co-authored-by: Korijn van Golen <k.vangolen@clinicalgraphics.com>
400: Validate bind group layouts by value r=kvark a=yanchith
This PR widens the comparisons done between two bind group layouts to also consider them equivalent if their vectors of `BindGroupLayoutBinding`s are equal.
Tested on various modifications of the cube example from wgpu-rs. https://gist.github.com/yanchith/56e15fe35658b14587ff9bfcbd53116fFixes#335
Co-authored-by: yanchith <yanchi.toth@gmail.com>
To make later bind group layout compatibility checks simpler (and
cheaper), deduplicate them on creation. If two bind group layouts with
same descriptors are requested, only one is created and the same id is
returned for both.
408: Handle adapter enumeration failures better r=kvark a=kvark
Fixes#406
It appears that the target system could support Vulkan but is misconfigured.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
