769: Implement and Validate all WebGPU Limits r=kvark a=cwfitzgerald
**Connections**
None?
**Description**
This adds all the limits that webgpu has currently. It also validates the values.
The main piece of code here is `BindingTypeMaxCountValidator` and `PerStageBindingTypeCounter` which provides the interface for figuring out the maximum per-stage counts in the pipeline. For each `BindGroupLayout` a `BindingTypeMaxCountValidator`is put together during creation using all of the bindings. Then the `BindingTypeMaxCountValidator`s are combined into a single max. This is then validated against the max limits.
Each commit should be independently testable and are grouped by responsibility.
**Testing**
I modified the wgpu-rs example framework to ask for extremely reduced limits and then tested various examples to verify it properly accepted/rejected based on the actual limit.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
766: Validate set_bind_group is within bounds of limit r=kvark a=cwfitzgerald
**Connections**
~~Don't think there are any.~~ Would provide a nicer error message for https://github.com/gfx-rs/wgpu-rs/issues/411.
**Description**
Implements checks related to our only limit.
**Testing**
Untested
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
763: Remove raw pointers from the render pipelines API r=kvark a=GabrielMajeri
**Connections**
Rust-ification of API, as part of #689
**Description**
The objective is to get rid of raw pointers in the render pipeline descriptor and associated structures.
**Testing**
Checked with `player` and the `trace` feature, and with `wgpu-rs` with the changes in https://github.com/gfx-rs/wgpu-rs/pull/425
Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
764: Remove UnsafeFeatures as we decided the top level guard is not useful r=cwfitzgerald a=kvark
**Connections**
Reverts part of #691 about unsafe extensions
**Description**
Top-level unsafe is not sound. We still need unsafety close to the spot where it's triggered.
**Testing**
untested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
759: Bump the maximum bind groups to 8 r=kvark a=kvark
**Connections**
https://github.com/gfx-rs/wgpu-rs/issues/411#issuecomment-653756154
**Description**
This is the hard upper bound. It can be 4, technically, but it would make sense to raise it to at least 8.
**Testing**
Untested, should work still.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
758: Require mapped buffers to be aligned r=cwfitzgerald a=kvark
**Connections**
Likely addresses https://github.com/gfx-rs/wgpu-rs/issues/420
**Description**
We require the size and offsets of mapping to be aligned to 4. This includes buffers mapped at creation.
It allows us to use buffer copy operations to sync the contents.
**Testing**
Not really tested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
757: Validate Dynamic Bindings are In-Bounds r=kvark a=cwfitzgerald
**Connections**
Closes#756
**Description**
Needed to store some basic info about all dynamic bindings in the bind group.
I wasn't exactly sure where to put the validation function, so I stuck it as an inherent function on the BindGroup. Can be moved if this isn't ideal.
I also moved offset alignment validation into the validation function to help reduce duplication between render/compute.
**Testing**
None of the examples use dynamic indexing, so it's hard to test this as is.
@FlorianUekermann could you possibly test this patch with your repro case?
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
754: Implement MultiDrawIndirect Extensions r=kvark a=cwfitzgerald
**Connections**
Closes#742.
**Description**
These extensions, especially when combined with binding indexing, allow the creation of extremely cpu-efficient gpu powered pipelines.
Adds two extensions allowing various types of multi-draw-indirect
- MULTI_DRAW_INDIRECT (giving `multi_draw_indirect` and `multi_draw_indexed_indirect`)
- MULTI_DRAW_INDIRECT_COUNT (giving `multi_draw_indirect_count` and `multi_draw_indexed_indirect_count`)
This adds what I believe to be an extra restriction on the `*count` family of functions when compared to the underlying api. The buffer _must_ be large enough to draw `max_count` draws, even if that many draws are never drawn. This makes these operations no more unsafe than indirect would be, which is currently safe.
I did not implement these for renderbundles, but there's no reason they couldn't work, so those branches are marked with `unimplemented` as opposed to `unreachable`.
Additional Changes:
- Added some validation to the normal `draw_*_indirect` functions to prevent buffer overruns.
- The DX12 gfx-hal backend requires the strides to _always_ be non-zero, so I modified the normal indirect draws to use explicit strides.
- Made device limits and features `pub(crate)` as they need to be checked in random places in the code.
**Testing**
The change was tested using a modified version of wgpu-rs's texture-array example using a variety of permutations. I have not been able to test regular MULTI_DRAW_INDIRECT on mac, but I see no reason why that wouldn't work.
https://github.com/gfx-rs/wgpu-rs/pull/414
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
755: Added independent blending to the list of required device features r=kvark a=Wumpf
Currently, using different blend modes on multiple render targets on the vulkan backend results in this validation error:
```
[2020-06-27T19:51:47Z ERROR gfx_backend_vulkan]
VALIDATION [VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605 (-884533293)] : Validation Error: [ VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605 ] Object 0: handle = 0x2ea18313250, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xcb4717d3 | Invalid Pipeline CreateInfo: If independent blend feature not enabled, all elements of pAttachments must be identical. The Vulkan spec states: If the independent blending feature is not enabled, all elements of pAttachments must be identical (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605)
object info: (type: DEVICE, hndl: 3204451480144)
```
This is caused by not requesting the independent blend feature from the device.
Given how the wgpu/webgpu API looks like (it makes it very easy to use independent blending) and that there is 100% coverage of this feature on the Vulkan [feature database](https://vulkan.gpuinfo.org/listfeatures.php), I suppose this is a bug, and here's the trivial fix for it 😃
If this is not meant to be required I'd like to make it an optional feature.
Tested manually in my personal project via wgpu-rs, using Vulkan backend.
(on this [commit](69b660ac5a), uses locally changed gfx-rs/wgpu)
Co-authored-by: Andreas Reich <r_andreas2@web.de>
753: Deduplicate BindGroupLayout by value r=cwfitzgerald a=kvark
**Connections**
Fixes#335
**Description**
BGL now has distinct `MultiRefCount` type with a bit of a hacky logic to support deduplication.
Good review is needed!
**Testing**
Ran wgpu-rs examples.
The actual new logic is NOT tested enough!
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
752: gfx-memory update r=trivial a=kvark
**Connections**
Switches gfx-extras to https://github.com/gfx-rs/gfx-extras/pull/18Fixes#750
**Description**
Includes important correctness fixes.
**Testing**
Tested on wgpu-rs examples on macOS.
Also, by @cwfitzgerald having the repro case of #750
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
751: Convert Extensions + Capabilities into Features r=kvark a=cwfitzgerald
**Connections**
Based on upcoming webgpu changes.
**Description**
Does what it says on the tin. The only notable change was classifying the AnisotropicFiltering extension as a WebGPU extension (per https://github.com/gpuweb/gpuweb/issues/696, but no idea if that's the correct interpretation)
**Testing**
Will be tested by upcoming wgpu-rs PR.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
748: Allow intra doc link resolution failures, because they actually succeed when they need to but rust doesnt know r=kvark a=rukai
**Description**
cargo doc will create a lot of warnings due to the intra doc links pointing to wgpu.
The links work fine, but the warnings are no good because they show up when any any crate dependent on wgpu runs cargo doc.
**Testing**
Ran cargo doc from wgpu-types:
* before: warnings from this crate.
* after: no warnings from this crate.
Ran cargo doc from wgpu:
* before: warnings from this crate
* after: no warnings from this crate
Co-authored-by: Rukai <rubickent@gmail.com>
747: Custom implement Debug for RenderCommand and ComputeCommand r=kvark a=kunalmohan
This would avoid unnecessarily long debug logs for Render and Compute passes to some extent. I am not sure if it would be helpful to print `dynamic_offsets` and `string_data` under `BasePass` without the content of related `Compute/Render Command`.
<!--**Connections**
_Link to the issues addressed by this PR, or dependent PRs in other repositories_
**Description**
_Describe what problem this is solving, and how it's solved._
This would avoid
**Testing**
_Explain how this change is tested._
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.
-->
Co-authored-by: Kunal Mohan <kunalmohan99@gmail.com>
749: Tweak the logging a bit to make debug level usable r=non-controversial a=kvark
**Connections**
Nothing
**Description**
We should have somewhat stricter guidelines on what is ok in Debug level and what not. Previously, we printed all the tracking state on each command buffer and each submit. Since these happen every frame, and the amount of stuff used by a command buffer is not really limited, this resulted in a ton of spam, hiding legitimate Debug messages.
This PR leaves the tracker state outputs for things that are one-time, such as bind groups and render bundles, but moves out the per-frame tracking to the Trace level.
**Testing**
Running wgpu-rs examples.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
744: Add `backends!` and `backends_map!` macros to code duplication r=kvark a=Kimundi
**Description**
The source code is doing a lot of things duplicated for each backend, which leads to code duplication and harder to read code.
This PR attempts to improve the situation by introducing a `backends!` and `backends_map!` for doing the code duplication automatically.
**Testing**
The macro have unit tests for checking that they work correctly.
Co-authored-by: Marvin Löbel <loebel.marvin@gmail.com>
740: First Phase of Tracing Transition r=kvark a=cwfitzgerald
## Connections
First step in the implementation of #491. https://github.com/gfx-rs/wgpu-rs/pull/395
## Description
This adds the tracing crate, implements a tracing "layer" for chrome tracing, and instruments every entrypoint into wgpu.
Tracing is added as a main dependency. A feature is added called `subscriber` which guards the tracing and default logger implementation, as that adds 3 dependencies.
The main macro is there to make creating a span a simple one line process. This macro will come in useful in the next couple stages. Use of this macro is used unqualified with it imported into scope as that style allows IntelliJ ides to actually find the macro.
I also removed a really annoying warning that was driving me crazy.
This PR does not make sure the logging output from tracing is up to snuff, that will be done when logging output and conversion is the priority.
Both commits should compile individually, so shouldn't need to be squashed.
## Testing
This PR was tested with the wgpu-rs PR on various examples, as well as my personal project.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
743: Derive Serialize and Deserialize for HostMap r=kvark a=kunalmohan
**Connections**
_Link to the issues addressed by this PR, or dependent PRs in other repositories_
**Description**
_Describe what problem this is solving, and how it's solved._
Also a switch from `f32::MAX` to `std::f32::MAX`
**Testing**
_Explain how this change is tested._
<!--
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.
-->
Co-authored-by: Kunal Mohan <kunalmohan99@gmail.com>
746: Fix RODS layout r=trivial a=kvark
**Connections**
Fixes a validation error on the water example:
> VALIDATION [UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout (1303270965)] : Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x5626e376bc90, name = Main Command Encoder, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | Submitted command buffer expects VkImage 0x390000000039[Depth Buffer] (subresource: aspectMask 0x2 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL.
object info: (type: COMMAND_BUFFER, hndl: 94725024955536, name: Main Command Encoder)
**Description**
The problem came from the fact that I totally refactored the part that figures out how attachments I used *after* I thought about the relevant layouts, and somehow let this bug slip in.
**Testing**
Tested on the water example.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
