468: Switch value of BufferUsage's INDIRECT and STORAGE_READ fields r=kvark a=almarklein
Closes#467. This makes the value of `INDIRECT` equal to it's value in the IDL spec. (`STORAGE_READ` is not present in the IDL spec.)
I changed the value in `resource.rs` and then ran `make ffi/wgpu.h`.
Co-authored-by: Almar Klein <almar.klein@gmail.com>
466: Refactored swapchain tracking r=sibling a=kvark
This is a sibling of #465 for master.
Fixes#227
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
462: Using default nsview if not provided by raw-window-handle r=kvark a=lmcgrath
Per #453 I've added some native code to get the default `NSView` if it's not provided by `RawWindowHandle`. This is to support libraries like SDL2 which expose an `NSWindow` but no `NSView`. I'm using the [`[NSWindow contentView]`](https://developer.apple.com/documentation/appkit/nswindow/1419160-contentview) property to get the `NSView`.
Co-authored-by: Logan McGrath <1755866+lmcgrath@users.noreply.github.com>
461: Add Clippy to CI, fix errors and most warnings r=kvark a=yanchith
A quick rundown of changes:
- Fixed instances of clippy error [not_unsafe_ptr_arg_deref](https://rust-lang.github.io/rust-clippy/master/index.html#not_unsafe_ptr_arg_deref): Some extern functions in wgpu-remote are now marked unsafe, as they accessed data behind raw pointer via `Box::from_raw` and `slice::from_raw_parts` (commit 741844cc2b)
- Fixed clippy warning [or_fun_call](https://rust-lang.github.io/rust-clippy/master/index.html#or_fun_call) by changing `unwrap_or` to `unwrap_or_else`
- Added `#[allow(clippy::range_plus_one)]` in places where ranges are constructed along with TODOs to fix upstream in gfx. The rule [range_plus_one](https://rust-lang.github.io/rust-clippy/master/index.html#range_plus_one) is great if you have everything in one crate, but the gfx hal structs expect `Range` instead of the more generic `RangeBounds` trait.
- Fixed quite a few clippy warnings [missing_safety_doc](https://rust-lang.github.io/rust-clippy/master/index.html#missing_safety_doc) in the trivial cases (`Box::from_raw` and `slice::from_raw_parts`).
There's still a few `missing_safety_doc` warnings left. They all have in common the usage of the unsafe functions `RawPass::encode` and `RawPass::encode_slice`. I think these could potentially be made safe - it seems like `RawPass` manages its invariants internally, but I might be missing something.
I didn't add CI code that posts the warnings to github PR comments, but if anyone is willing to pick that up, this could help: https://github.com/dpobel/damien.pobel.fr/pull/62/filesFixes: #422
Co-authored-by: yanchith <yanchi.toth@gmail.com>
Only two unsafe functions were used internally:
- `slice::from_raw_parts`
- `Box::from_raw`
The safety messages are adapted from the safety messages of these functions.
448: Fix framebuffers not always being cleaned up if invalid r=kvark a=LaylConway
This changes framebuffers to be cleaned up if only one view is cleaned up, instead of if all views are cleaned up. This is necessary because currently, at least for me, swapchain images will have a different view every frame. This means that if other views continue to exist between frames, the resulting framebuffers will never be cleaned up.
Fixes#447
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
449: Fix missing memory release r=kvark a=zakorgy
This fixes the issue where the underlying memory of buffers and textures not released when calling `Global::delete`.
cc @kvark
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/gfx-rs/wgpu/449)
<!-- Reviewable:end -->
Co-authored-by: Zakor Gyula <gyula.zakor@h-lab.eu>
PowerPreference::Default will now prefer discrete GPUs
when on AC power and will prefer integrated GPUs while
on battery power (i.e. the battery is discharging).
439: Refactor usage tracking to be truly sparse r=dependency a=kvark
~~This is a required step towards #438 . We want to be tracking the usage by only having resource IDs around, not resources themselves. So we aren't going to have access to `full_selector`.~~
It's also streamlining some of the verbose parts of the internal API for usage tracking.
It also uses `SmallVec` for the texture tracker ranges, essentially making it lightweight for most cases (where the layer count is 1).
Compromises:
- removes `SEPARATE_DEPTH_STENCIL_STATES` support. It's not in the near future to enable it anyway.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
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>
