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>
* Add initial pomelo glsl work
* Fix ref to glsl_old
* Fix idents with numbers in lexer
* Use glsl_new for .vert in convert example
Controlled by PREFER_GLSL_NEW=1 env var
Also add simple test files
* Start making parser look like spec
* Port 'old' lex.rs to glsl_new
* Apply fixes after rebasing
* Fix clippy issue
* Fix PR comments
- Make into optional feature glsl-new
- Minor code style improvements
23: Bump libloading to 0.6 r=msiglreith a=cwfitzgerald
They got rid of their typedef for their result type. Strange.
Breaking change, so can't go out in a patch release.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
414: Implement MultiDrawIndirect Extensions r=kvark a=cwfitzgerald
The wgpu-rs component of https://github.com/gfx-rs/wgpu/pull/754.
I didn't include the modifications to the example as they are particularly awful and ugly. One of my next steps following this is to make an example of both binding indexing and these multi-draw extensions.
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>
413: Improve docs for main crate and `hello-triangle` example r=cwfitzgerald,kvark a=GabrielMajeri
Some minor fixes for the main crate docs, as well as some comments in the `hello-triangle` example.
Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
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>
408: Staging belt r=kyren a=kvark
Implementing the belt itself isn't too hard, but integrating it with the example framework and winit's event loop is somewhat challenging. Perhaps, there needs to be a `LocalSpawner` parameter to `render()` like I did [in vange-rs](e7bc944ef5/bin/boilerplate.rs (L26))?
Edit: code is all ready and shiny... but it does NOT work. Buffers don't come back from mapping for some reason.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Co-authored-by: kyren <kerriganw@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>
400: Added test for "capture" example r=kvark a=bfrazho
I've added a test to validate the capture example. I was planning on using the existing "screenshot.png" that was in there for the assertion for the test, but apparently was slightly different from the one that I was generating. I ended up replacing the screenshot.png with what the test was generating.
I'm a little concerned that they were different from the start, but maybe the png generating library made some small changes over time. I did check to make sure that it generated the same png on Windows and Linux on the same computer.
Let me know if there is anything that you would like me to change!
Co-authored-by: Brian <brian@linux-ccip.lan>
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>
removed some warnings in the capture test about not handling results, and put expect messages around them
separated png logic from the rest of gpu logic in the capture example
refactored capture test to do assertion based on data rather than the output png
switched assertion for capture test to only check for red pixels instead of comparing to a raw buffer as a file
cleaned up capture example test to get rid of warnings
407: Build Docs with Nightly r=kvark a=cwfitzgerald
This builds docs with nightly by default. We use intra-doc links which is currently only supported with nightly. docs.rs also uses the latest nightly to build our code, so this will match behavior with docs.rs. I added a fallback to stable in case nightly has issues so we still have working docs.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
