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>
* Basic glsl support
* Miscellaneous fixes and vertex shader works
* Added rudimentary texture and sampler support
* Basic preprocessor
* Added preprocessor if macros
* Pass tests and handle floats correctly
* Fix preprocessor if wrong precedence ordering when using macros
Refractor for the glsl parser
Partial primary expression parser
* Fix all clippy errors
* Cleanup
* Rollback formatting changes in lib.rs
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>
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>
353: Properly honor `mapped_at_creation` in `Device::create_buffer` r=cwfitzgerald a=kyren
The returned `Buffer` should immediately be mappable. Fixes#351
Co-authored-by: kyren <kerriganw@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>
348: Add aribitrary texture size handling to the capture example r=me a=rukai
* User can specify width + height via arguments.
* Defaults to (100, 200) when no arguments. Odd values chosen to make it more likely to pick up issues when testing.
* Converts from bgra as I believe that is the most commonly supported format for swapchains?
Co-authored-by: Rukai <rubickent@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>
