969: Never prefer CPU devices over GPUs r=kvark a=myfreeweb
Mesa (development repo) now has a software renderer for Vulkan (`lavapipe`), it is incomplete for now and can't handle iced, so my app exploded after a mesa rebuild :)
Looks like someone forgot to push CPU renderers to the lowest priority.
(This commit should be cherry-pickable onto master I think, since this code hasn't really changed)
Co-authored-by: Greg V <greg@unrelenting.technology>
958: [0.6] fix device feature requests r=cwfitzgerald a=kvark
**Connections**
Looks like we were requesting a little bit too much?
Also includes #936 and #957
**Description**
Fix the features requested.
**Testing**
Confirmed by the virtue of `println!` :)
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Co-authored-by: Kunal Mohan <kunalmohan99@gmail.com>
886: [0.6] Backport buffer and texture overrun error messages r=kvark a=cwfitzgerald
**Connections**
#885 but neutered to be a non-breaking change.
**Description**
The original error message talked only about the destination buffer, which is very confusing as the cause of the overrun could be the source buffer.
Not worth a release on its own, but next time there's a release, we can get this fixed.
**Testing**
Strings only.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
881: Factor wgpu-subscriber into its own repo r=kvark a=cwfitzgerald
**Connections**
Closes#871
**Description**
Removes wgpu-subscriber crate into its own repo.
**Testing**
Compile only change.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
880: Port to gfx-hal-0.6 r=kvark a=kvark
This got a little more involved than I hoped, because of https://github.com/rust-lang/rust/issues/34433 which is unfortunately closed.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
877: Add image cube array feature. r=kvark a=StarArawn
**Connections**
None
**Description**
Enable `IMAGE_CUBE_ARRAY` in vulkan and dx12. Note: Currently this will cause metal to break as the `available_features` from the physical device will never include `IMAGE_CUBE_ARRAY`. Thus I'm opening this as a draft until gfx-hal metal can check and pass the feature on.
**Testing**
<!--
Non-trivial functional changes would need to be tested through:
- [wgpu-rs](https://github.com/gfx-rs/wgpu-rs) - test the examples.
- [wgpu-native](https://github.com/gfx-rs/wgpu-native/) - check the generated C header for sanity.
Ideally, a PR needs to link to the draft PRs in these projects with relevant modifications.
See https://github.com/gfx-rs/wgpu/pull/666 for an example.
If you can add a unit/integration test here in `wgpu`, that would be best.
-->
I can test this with my repo using wgpu-rs here which uses cube arrays:
https://github.com/StarArawn/harmony/
Co-authored-by: John Mitchell <toasterthegamer@gmail.com>
876: Fix support for d24unorm format r=kvark a=kvark
**Connections**
fixes https://github.com/kvark/vange-rs/pull/121 on some platforms
**Description**
We used to associate `D24Plus` with internal `D24S8`. This results in assuming that it has both DEPTH + STENCIL. Creating a binding from it then fails with the `All` aspect, since you can't view both. This is unexpected, since the user creates `D24Plus` with just a single aspect.
**Testing**
None needed
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
875: Add labels to pipelines r=trivial a=kvark
This isn't functional until gfx-hal-0.6 is published, but the API is there.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
873: Grand cleanup and refactor of the descriptors in the API r=cwfitzgerald,grovesNL a=kvark
**Connections**
Cleanup follows https://github.com/gfx-rs/wgpu-rs/pull/501Fixes#871Fixes#848
**Description**
There is a lot of small and big things crumbled in here.
The major one is where descriptors live, and how they are parametrized. Logic is the following:
- if something is useful by wgpu-rs's API leave it in `wgpu-types`
- if *in addition* it's useful to `wgpu-native`(i.e. has `repr(C)`), we possibly parametrize it (currently, only label is).
- otherwise, the type is moved to `wgpu-core` and stripped of generics
- remove all the builders
Some medium-sized things:
- moves the subscriber out (#871)
- moves the `RenderCommand` into the `draw` module (which is meant to contain shared things)
- makes `TextureViewDescriptor` fields optional, but receives it directly now (#848)
- moves stencil stuff out into `StencilStateDescriptor`, so that we can derive `Default` for it
- stop accepting raw strings for labels in the `Device` API: neither the clients, or gfx-rs need that shape, and it can't be safe
Some smaller things:
- using NonZeroU8 for anisotropy
- using NonZeroU32 for descriptor count
- putting sampler addressing modes into an array
- add labels to command buffers and pipeline layouts
- improves errors for exceeding binding limits
**Testing**
Tested on https://github.com/gfx-rs/wgpu-rs/pull/503
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
872: Respect texture view aspect on creation r=cwfitzgerald a=kvark
**Connections**
Fixing https://github.com/gfx-rs/wgpu-rs/issues/498 (but needs wgpu-rs update then)
**Description**
We added the aspect field to texture view descriptor but didn't respect it properly.
We do that now, and also disallow Depth-Stencil sampled views
**Testing**
Used the modified water example for testing.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
870: Implicit layout r=cwfitzgerald a=kvark
**Connections**
Closes#868
**Description**
The implementation can be split into 3 parts:
1. reflecting the shader for binding expectations, and building a bind entry map from it, merging them between stages. This is only done for shaders that can be reflected, and we error on the rest, for now.
2. based on this info, create new bind group layouts and pipeline layouts. The tricky part here is that we can't generate the ID out of thin air, so we have to pass them into the `create_xx_pipeline` function, which now also returns the number of IDs it consumed, allowing the client to free the rest.
3. API changes in the descriptors, new methods to obtain the bind group layouts from a pipeline
**Testing**
This isn't tested, but I think it's fine: it doesn't affect the old path, and we'll be testing the new path while improving Naga and our reflection anyway.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
