838: wait for buffer to be done in the player r=cwfitzgerald a=kvark
**Connections**
Fixes our code enough to replay #834 without issues. Doesn't help to solve the original problem though.
**Description**
There are two things in here:
1. don't deduplicate the BGLs if we are not generating new IDs at this layer. This helps Servo/Gecko/player. cc @kunalmohan
2. have an option in `buffer_destroy` to *actually* kill it, at the cost of blocking on GPU sometimes. This is required for the player, since the very next command may try to reuse the ID.
**Testing**
Tested on the trace in #834
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
839: Fix push constant pipeline invalidation r=kvark a=cwfitzgerald
**Connections**
Fixes#821
**Description**
We need to invalidate everything if push constants change. This code is kinda ugly but this is try three and it's the least terrible I got.
**Testing**
Pinging @Wumpf :)
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
479: Split framework limit situation into requested/required r=kvark a=cwfitzgerald
Requiring individual examples be responsible for panicing if their features aren't supported is a bit bug-prone, so this encodes requirements in the framework and enforces it in the framework.
Additionally made the verbs consistent.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
832: Return errors from device functions r=kvark a=GabrielMajeri
**Connections**
Part of #638
**Description**
Lots of changes, but they should be easily reviewable commit-by-commit.
- Error types for most of the fallible resource creation errors in `device/mod.rs`
- Removed assertions and replaced them with error types
- All of the `BufferMap`, `BufferNotMapped` etc. errors were united in a single `BufferAccessError`, since it was pretty weird to have so many overlapping error types.
- Removed all `unwrap`s of `gfx-hal` errors - they are now returned to the caller.
**Testing**
Checked with core and tested with `wgpu-rs` (see https://github.com/gfx-rs/wgpu-rs/pull/469)
Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
475: Made RenderBundleEncoder derive Debug r=kvark a=Andful
This is a continuation of the pull request #466 and should resolve the issue #458.
Co-authored-by: Andrea Nardi <buongiorno19972@gmail.com>
833: Switch pipeline flag to mutation of depth/stencil r=startoaster a=kvark
**Connections**
Reported on the matrix
**Description**
If the pass mutates depth/stencil, but the pipeline doesn't, it's not a bug!
**Testing**
on it...
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
829: Fix typo in BufferUsage docs r=kvark a=cwfitzgerald
**Connections**
A couple people have bugged me about this in the past.
**Description**
Docs were wrong, they are now right.
**Testing**
Read it again :)
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
466: add debug trait for public types r=kvark a=Andful
This pull request is to resolve the issue #458.
This pull request is still incomplete. The only problematic trait is `RenderBundleEncoder`.
For the native version, `RenderBundleEncoder` does not implement `Debug`. This would have to be implemented in the wgpu project.
FYI, Context does not need to implement `Debug`. The type that implements `Context` is used directly, i.e. `Arc<C>` is used and not `Arc<dyn Context>`
Co-authored-by: Andrea Nardi <buongiorno19972@gmail.com>
827: Make RenderBundleEncoder derive Debug r=kvark a=Andful
**Connections**
This pull request originated from https://github.com/gfx-rs/wgpu-rs/pull/466. This change is needed to make public types in `wgpu-rs` derive debug.
**Description**
Make RenderBundleEncoder derive Debug.
**Testing**
Co-authored-by: Andrea Nardi <buongiorno19972@gmail.com>
826: Detach MultiRefCount from RefCount completely r=cwfitzgerald a=kvark
**Connections**
Fixes#823
**Description**
The old way of trying to mix the new `MultiRefCount` with bits of existing infra with `RefCount` was not correct at all. We'd get into a situation where the refcount was already deleted, but the object is alive, for example. This PR detaches them completely.
To clarify: it's not great at all that we have manual refcounting on BGLs. And this de-duplication crap caused much more trouble than it's worth...
**Testing**
Tested on the wonderful example provided by @tiberiusferreira
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
825: Add depth clamping support r=cwfitzgerald a=kvark
**Connections**
Implements https://github.com/gpuweb/gpuweb/pull/900
**Description**
Depth clamping is useful for shadow mapping and stuff. We'd want to use it in our `shadow` example.
**Testing**
Untested, should work though :)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
824: Naga update, remove spirv_headers dependency r=cwfitzgerald a=kvark
**Connections**
Many changes went into Naga, including https://github.com/gfx-rs/naga/pull/81
**Description**
We'll get better SPIR-V parsing and even a bit of WGSL validation.
**Testing**
Working on it...
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
442: replace vertex_format_size macro with VertexFormat size function r=kvark a=bootra-dev
This pull request depends on https://github.com/gfx-rs/wgpu/pull/802
I'm not sure if multiple pull requests is the right way to handle this - let me know if I need to use another workflow.
Co-authored-by: bootra-dev <bootragames@gmail.com>
453: Added Static Lifetime to Statically Loaded SPIR-V Modules r=kvark a=Andful
The commit enables `include_spirv!` to return a `ShaderModuleSource<'static>`.
This allows `ShaderModuleSource` to outlive the context in which `include_spirv!` was called in.
An example where this implementation would work but the previews would not is the following.
```rust
fn get_vertex_module<'a>() -> wgpu::ShaderModuleSource<'a> {
wgpu::include_spirv!("shader.vert.spv")
}
let vs_module = device.create_shader_module(get_vertex_module());
```
Also it makes logical sense for a statically loaded module to have a static lifetime.
The only downside that this change might bring is the redundant presence of the binary string (the non aligned binary string and the aligned binary string) but from the produced assembly I could only find one copy of the binary string so I don't think this is the case.
Co-authored-by: Andrea Nardi <buongiorno19972@gmail.com>