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>
369: Implement SAMPLED_TEXTURE_ARRAY_NON_UNIFORM_INDEXING r=kvark a=cwfitzgerald
This implements https://github.com/gfx-rs/wgpu/pull/715 in wgpu-rs. I haven't changed the example, as I want to actually think up a better example to use and didn't want that to block this. It will change in the future however.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@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>
370: API update for RODS2 r=cwfitzgerald a=kvark
Reflects upstream changes in https://github.com/gfx-rs/wgpu/pull/716
I'm not too happy about the API just yet, has another idea that I'm going to discuss with the group on Monday, hopefully. But we need to get going and not block other wgpu-rs changes, so this should land in some way.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.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>
360: Implement TEXTURE_BINDING_ARRAY extension r=kvark a=cwfitzgerald
This extends https://github.com/gfx-rs/wgpu/pull/711 into wgpu-rs.
Notable changes:
- Added an example showing off both this extension and the future descriptor indexing extension.
- Changed the framework so there is a static function showing what extensions you need. This is provided by the trait,, which defaults to no extensions, so existing examples and new ones don't have to care about extensions.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@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>
356: Add generic ranges to buffer mapping api and make it safe. r=kvark a=lachlansneff
[Rendered](https://charted.space/notes/wgpu-rs/wgpu/struct.Buffer.html)
The safety issues with the current api (being able to unmap while still holding a slice to mapped data) are fixed by having `get_mapped_range` and `get_mapped_range_mut` return `BufferView` and `BufferViewMut`, which notify the buffer that those ranges are no longer being used when they're dropped. `Buffer.unmap` asserts that the list of mapped ranges is empty, therefore it is safe.
Co-authored-by: Lachlan Sneff <lachlan.sneff@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>
350: Implement Extensions Interface r=kvark a=cwfitzgerald
This implements https://github.com/gfx-rs/wgpu/pull/703 in wgpu-rs. Notable changes include the removal of the anisotropic field from the examples, in favor of the now mandatory `..Default::default()` syntax.
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>
