726: Basic support for minBufferBindingSize r=cwfitzgerald a=kvark
**Connections**
Has basic (partial) implementation of https://github.com/gpuweb/gpuweb/pull/678
wgpu-rs update - https://github.com/gfx-rs/wgpu-rs/pull/377
**Description**
This change allows users to optionally specify the expected minimum binding size for buffers. We are then validating this against both the pipelines and bind groups.
If it's not provided, we'll need to validate at draw time - this PR doesn't do this (focus on API changes first).
It also moves out the `read_spirv`, since wgpu-types wasn't the right home for it ever.
**Testing**
Tested on wgpu-rs examples
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
719: Implement debug marker support r=kvark a=krupitskas
**Connections**
Closes https://github.com/gfx-rs/wgpu/issues/697
**Description**
Looks like because I've once pushed forward reset branch to my master, previous pull request https://github.com/gfx-rs/wgpu/pull/713
show that there no commits and it automatically was closed :/
**Testing**
Not tested yet
Co-authored-by: Nikita Krupitskas <krupitskas@icloud.com>
727: Update gfx-memory to the latest commit r=kvark a=rukai
**Description**
In order to test potential fixes for https://github.com/gfx-rs/wgpu-rs/issues/363 we need wgpu master to be able to easily test changes to gfx-memory.
Assuming we dont have any large regressions I think it could be nice to release wgpu 0.6 before merging this. I dont mind either way though.
**Testing**
I ran some wgpu-rs examples.
Co-authored-by: Rukai <rubickent@gmail.com>
723: Always use DepthStencilReadOnlyOptimal for sampled depth r=kvark a=kvark
**Connections**
This is a follow-up to #712 that reverts the API changes but also fixes our internal logic to work better.
**Description**
It solves the problem of image layouts by always using a RODS layout on depth images, when sampled.
**Testing**
Tested on https://github.com/gfx-rs/wgpu-rs/pull/375
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
722: Refactor tracking of device last completed submission r=kvark a=kvark
**Connections**
Fixes https://github.com/gfx-rs/wgpu-rs/issues/358
**Description**
We used to track the next submission index in `device.life_guard.submission_index` atomic. This PR changes that to point to the last *done* submission, and also introduces a non-atomic field to keep track of the current/next submission.
This allows us to avoid waiting on the frame semaphore on presentation if the relevant submission is done by then.
**Testing**
Not tested!
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
717: Implement Capability/Extension Split r=kvark a=cwfitzgerald
## Connections
Follow up to a discussion we had on #wgpu:matrix.org.
## Description
Splits capabilities and extensions so that extensions are things you ask for and possibly change behavior and capabilities are passively enabled when their extension (if any) are enabled.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
720: Fix validation errors + panics on empty buffers r=kvark a=rukai
**Description**
My previous PR left a vulkan validation error when creating an empty buffer.
This PR fixes that and also fixes a panic preventing the compute-example from running with no elements.
**Testing**
Unit test added in wgpu-rs PR. https://github.com/gfx-rs/wgpu-rs/pull/373
<!--
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: Rukai <rubickent@gmail.com>
716: Add RODS texture binding property r=cwfitzgerald a=kvark
This is a follow-up to #712, which I screwed up right before it got in. Fortunately, we still need the code that went in, we just need a little bit more :)
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
712: RODS part 2 r=cwfitzgerald a=kvark
**Connections**
Unblocks https://github.com/gfx-rs/wgpu-rs/issues/359
Is a follow-up to RODS part 1 - #685
**Description**
There is a few things in here.
Thing 1: Stronger assertions on the load/store ops of the depth & stencil.
### Thing 2: rewritten tracking of render attachments
Background: from the usage tracker point of view, each subresource can be in either "extend" mode, where it accumulates a single combined usage, or in the "replace" mode, where it goes from one usage to another, producing the relevant transitions on the way.
The problem turned out to come from the fact that the render pass attachments were always tracked in "replace" mode. This is needed because their track don't have a single state: render pass itself encodes a transition of attachments. However, it also means that there was no way to "extend" the usage in RODS scenarios...
So I could see two ways to address this:
- re-achitecture the tracking a bit more in general, representing it as a sequence of merges.
- introduce the "prepend()" tracking operator that's *only* used for render pass attachments
I opted for the latter as it seems much less intrusive. The render pass attachments accumulate their usage like everything else in the "extend mode". But right before we are inserting the transitions (between the active command buffer and the pass), we turn the tracking of the attachments from "extend" into "replace" mode by installing the "first" usage according to what we expect it to be.
### Thing 3: missing API for RODS bind groups
The original RODS design missed a problem with Vulkan image layouts. When creating a bind group, one has to specify what layout the image will be in. We always used `ShaderReadOnlyOptimal` until now for texture views. However, in RODS scenarios this has to be `DepthStencilReadOnlyOptimal`. Luckily, it's compatible with sampling from the shader, but we still need to know about this when creating the bind group.
**Testing**
Tested on the modified water example provided in https://github.com/gfx-rs/wgpu-rs/issues/359#issuecomment-642167269
Added a few tests to the buffer implementation of the new `prepend()` operator.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
715: Implement SAMPLED_TEXTURE_ARRAY_NON_UNIFORM_INDEXING r=kvark a=cwfitzgerald
## Connections
Closes#483. Extends support for #106.
## Description
This forwards the descriptor indexing features gfx-hal up to wgpu.
Note this PR also changes the name of the `TEXTURE_BINDING_ARRAY` to `SAMPLED_TEXTURE_BINDING_ARRAY` to be more consistent with extensions.
## Testing
Texture-array example was simply extended to use descriptor indexing. This works on all platforms that the feature is supported. (thanks @stararawn)
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
714: Track buffers and textures in the future submissions r=cwfitzgerald a=kvark
**Connections**
Fixes https://github.com/gfx-rs/wgpu-rs/issues/362
**Description**
When we do `write_buffer` or have it mapped on creation, we record the copy command in a "pending command buffer", which is only actually executed on the next submission. We adjust the submission index on the buffer accordingly.
If the buffer is dropped *before* the next submission, and there happens to be a `maintain()` step, there is code that checks if the buffer-associated submission is one of the currently executing ones. If it doesn't fine an active one, it considers the last-used submission to already be done with, which is precisely what is not happening here, since the submission hasn't been scheduled yet.
The solution here is to always defer suspecting buffers and textures for deletion till the next submission. The buffers and textures are the only objects that may have "future" submission index, due to `write_buffer` and `write_texture`.
**Testing**
Confirmed on Linux.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
286: RenderBundle support r=cwfitzgerald a=kvark
Implements the API of https://github.com/gpuweb/gpuweb/pull/301
The general concept here is having re-usable command streams, which seems much desired given that our command buffers are not reusable.
Currently, only "software" render bundles are supported. That means, they are just smaller chunks of render pass commands, not backed by any driver object.
TODO:
- [x] https://github.com/gfx-rs/wgpu-rs/pull/357
- [x] https://github.com/gfx-rs/wgpu-native/pull/37
- [x] figure out the lifetime solution
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
This is a major change in how the bundles are implemented. Instead of
transparently injecting them into the pass command stream, we are now
treating bundles as first-class API objects and API tracing them
accordingly. The bundle contains a normalized command stream that is
very easy to inject into a native command buffer multiple times.
711: Implement Descriptor Array Extension r=kvark a=cwfitzgerald
## Connections
Blocked on https://github.com/gfx-rs/gfx/pull/3269 and does some funky git overrides to get CI to return meaningful results what will be removed once that PR lands and is published.
## Description
This PR implements the `TEXTURE_BINDING_ARRAY` native extension. This allows users to specify a uniform sized array of textures for use in shaders.
As a corollary, this PR rustifies the Bind Group and Bind Group Layout interface. Two main actions were taken when doing this:
- Types that were able to be shared among wgt, wgc, and wgpu-rs were moved into wgt.
- Types that had references to other wgpu-rs specific structures were duplicated into wgc with wgpu-rs structures replaced with the appropriate ID. Notes were added to the wgc types that they were duplicated directly from wgpu-rs.
From what I can tell, this resulted in a significant reduction in code complexity when dealing with bind groups, favoring strong types over runtime assertions.
Naga validation of arrays of textures was not implemented.
Documentation was added to extensions to help users understand what underlying tech was being relied on as well as the platforms it should be expected to work on. I think this pattern should be implemented across the board for extensions as it makes them much more user friendly to use.
## Testing
There is an example included in the wgpu-rs PR which was used for testing this feature. It worked on DX12, Vulkan, and Metal (MSL > 2.0), as was expected.
Additionally the other examples were run and are still verified to run.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
710: Empty buffers are created internally with a size of 1 r=cwfitzgerald a=rukai
**Connections**
closes https://github.com/gfx-rs/wgpu/issues/709
**Description**
Empty buffers can be succesfully created.
**Testing**
Tested on my project and it resolves the above issue.
Co-authored-by: Rukai <rubickent@gmail.com>
708: Implement Mappable Primary Buffers Extension r=kvark a=cwfitzgerald
**Connections**
#675 made `MAP_WRITE | STORAGE` on buffers not possible. This extension re-enables it.
**Description**
UMA systems rejoice everywhere.
**Testing**
Hopefully it didn't break since it was usable a week or so ago, so this shouldn't need testing...
**Review Notes**
The name could be changed, particularly if primary has a certain meaning wrt buffers. It just seemed a reasonable description.
Knowing my luck, I got the bitflags call wrong...
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
707: Implement Bounds Checking on Buffers to Buffer and Texture Copies r=kvark a=cwfitzgerald
**Connections**
Closes#362, closes#554
This addresses issues found by @gretchenfrage when accidentally writing off the end of a texture causing a DEVICE_LOST error.
**Description**
Adds bounds checks to write_texture and write_buffer, and copy_texture_to_texture and friends. The bounds checking functions themselves follow guidance from the webgpu standard.
This doesn't make wgpu 100% to all the checks required by the standard, but takes care of the ones related to bounds and buffer overruns.
**Testing**
I tested this against all the examples, including intentionally making mistakes in texture copies, with this successfully catching those errors.
**Review Notes**
This code should be picked through fairly closely, as it's very likely there's some typos due to the close-but-not-quite repetition that these tests require. There's a bunch of LOC, but they are fairly boring and should be easy to understand.
I have tried to give assert messages that are as descriptive as possible, but if there is a message that could be changed to be more clear, let me know.
One thing that could change is the location of the functions. I left them where I originally wrote them, before I realized that the functions on queue also needed bounds checking, but they could have a better home elsewhere, maybe even their own file.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
706: Return errors on create_render_pipeline r=cwfitzgerald a=kvark
This is a follow-up to #705 that switches `create_render_pipeline` to return `Result`.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
705: Shader input/output validation r=cwfitzgerald a=kvark
**Connections**
Fixes#269
It still has a few gaps (like the `storage_texture_format` matching, bugs, optional validation), but the main logic is there. Anything else should come in smaller issues as a follow-up.
**Description**
The main goal of this PR is to validate:
- vertex input stage against VS inputs
- VS outputs against FS inputs
- FS outputs against the pipeline attachment formats
I figured that `WGPU_SHADER_VALIDATION` environment is not a great path forward. It doesn't help engine authors, for example. So I'm switching it to just a boolean field in `DeviceDescriptor`. Hopefully, we'll remove it soon :)
**Testing**
Just running wgpu-rs examples - https://github.com/gfx-rs/wgpu-rs/pull/354
Review notes: the commit in the middle just moves stuff around. I think it's easier to just review the first and the last commit, ignoring the middle.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
704: Pipeline layout validation r=cwfitzgerald a=kvark
**Connections**
Implements a solid part of #269
Starts converting the function to return results, related to #638
cc @GabrielMajeri
**Description**
This change matches shader bindings against the pipeline layout. It's *mostly* complete, minus some bugs and not handling the `storage_texture_format` properly.
The risk here is that Naga reflection may have bugs, or our validation may have bugs, and we don't want to break the user content while this is in flux. So the PR introduces an internal `WGPU_SHADER_VALIDATION` environment variable. Switching it to "0" skips Naga shader parsing completely and allows the users to unsafely use the API.
Another aspect of the PR is that some of the functions now return `Result`. The way I see us proceeding is that any errors that we don't expect users to handle should result in panics when `wgpu` is used natively (i.e. not from a browser). These panics would happen in the "direct" backend of wgpu-rs (as well as in wgpu-native), but the `Result` would not be exposed to wgpu-rs, so that it matches the Web behavior.
At the same time, browser implementations (Gecko and Servo) will check the result on their GPU process and implement the WebGPU error model accordingly. This means `wgpu-core` can be super Rusty and safe.
**Testing**
Running on wgpu-rs examples. Most of them fail to get parsed by Naga, but `boids` succeeds and passes validation 🎉
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
703: Implement Extensions Interface r=kvark a=cwfitzgerald
## Description
This is the first step of implementing #691. This implements the described changes to all the core structs and to `SamplerDescriptor`. I intend this PR to be an example of what the plan looks like. If we think this works, we can roll out the rest of the changes either in bulk or as we need them.
The rolling out of this is also tied to the rolling out of #689. Hopefully the macro work done in https://github.com/gfx-rs/wgpu-native/pull/34 will make this easier.
## Questions
One outstanding question I had is what the default values for lod_min/max should be. As of right now I just derive default, which puts them at zero, which is probably a reasonable default, though most of the examples use -100, 100 which is normally what you use when doing mipmapping.
## TODO:
- [ ] Discuss if this meets our needs
- [x] Implement this in wgpu-rs (https://github.com/gfx-rs/wgpu-rs/pull/350)
- [ ] Implement this in wgpu-native
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
702: Fix SwapChainOutput Related Segfault r=kvark a=cwfitzgerald
If a user accidentally recreates a swapchain after grabbing a SwapChainOutput, then renders to it, this will trigger a segfault on render. This can be reproduced by replacing the get_next_frame code in any example with:
```rust
let frame = swap_chain
.get_next_frame()
.expect("Failed to acquire next swap chain texture")
.output;
device.create_swap_chain(&surface, &sc_desc);
```
I have tested the examples, and they still work after this change, and it correctly detects this condition.
Oddly enough the following code does not panic, nor actually raise any errors, even with this PR.
```rust
let tmp = device.create_swap_chain(&surface, &sc_desc);
let frame = swap_chain
.get_next_frame()
.expect("Failed to acquire next swap chain texture")
.output;
swap_chain = tmp;
```
I'm not entirely sure why.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
