281: The Context trait r=grovesNL a=kvark
The main motivation here is to avoid blocking the wgpu-core updates by `wgpu-native`. Instead, `wgpu-native` becomes a branch, and the dependency of `wgpu-rs` -> `wgpu-native` starts adhering to the contract/API of the standard webgpu-native headers.
The biggest change is the introduction of the Context trait. I recall us discussing 2 downsides to having this trait:
1. inconvenient for the users to include. This is a non-issue here, since it's private.
2. more code to maintain. This is less of an issue if we aim to have 3 backends.
What this gives in return is a well established contract with the backends. Unlike gfx-rs, the backend code is right here, a part of the crate, so the contract is only for internal use.
Fixes#156 : the "direct" implementation of it goes straight to wgpu-core. What this gives us is less overhead for command recording, since there is no longer an extra indirection on every command, and no heap allocation at the end of a render pass.
The downside of this PR is one extra `Arc` (with addref) per object.
This commit also has small improvements:
- consuming command buffers on submit (Fixes#267)
- Instance type
- proper call to destructors
- fallible `request_device`
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Main change here is the introduction of the Context trait.
The "direct" implementation of it goes straight to wgpu-core.
This commit also has small improvements:
- consuming command buffers on submit
- Instance type
- proper call to destructors
When looking into wgpu-rs as a replacement for WebGL I went to the
examples directory on GitHub to browse for a bit.
I wanted to see some of the examples at a glance without needing to
clone the repository.
This commit enables that by adding a README to each example with a
description of the example and screenshots / example output.
In a few cases the description is a bit redundant - but my hope is that
in the future we can improve all the READMEs.
Being a web API and thus very accessible, WebGPU could end up being many
people's first introduction to graphics programming so the lower we make
the barrier the better.
615: Use General allocator at all times for now r=grovesNL a=kvark
In all user-managed resources, we don't have control of the lifetime. Since we don't know when it's released, we can't use any more specific allocator kind than `General`.
Previously, we assumed that buffers created for MAP_READ+COPY_SRC, for example, were one-time buffers created to copy data. However, there appear to be cases where they were used to fill data in once, and then persistently used as a copy source destination.
In the future, one WebGPU data transfer story is settled, we'll be able to use `Linear` kind again for all internally managed uploads. I.e. writeBuffer, writeTexture, and createBuffeMappedOnlyAtStart.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
271: Improve docs for BindingType r=kvark a=HalfVoxel
I think everything should be correct.
The readonly flags seem obvious at face value, but I couldn't find anything in the specifications about them (other than some unrelated validation), so I didn't add any documentation for those fields.
Co-authored-by: Aron Granberg <aron.granberg@gmail.com>
262: Reverse srgb in hello-triangle r=kvark a=grovesNL
Reverse srgb support in hello-triangle (these were backwards by mistake)
Co-authored-by: Joshua Groves <josh@joshgroves.com>
264: Use opaque texels in mipmap example r=kvark a=grovesNL
This fixes rendering for the mipmap example in Nightly
Co-authored-by: Joshua Groves <josh@joshgroves.com>
596: Remove wgpu-native and wgpu-remote r=grovesNL a=kvark
Closes#587
I'm still not sure if it's a good idea. Feedback is welcome!
For instance, even after we remove these two things, the repo will still contain a bunch of logic that Gecko wouldn't necessarily be interested in, such as the surface/swapchains logic.
It's also not clear to me how to properly organize the workflow with the wgpu-native being separate (btw, it's https://github.com/gfx-rs/wgpu-native). Do we still have the workspace here? Or do we just introduce a separate repo that will include all the stuff as sub-modules and have a single workspace?
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
598: Enable READ access for texture storage r=kvark a=kvark
This is a short-term workaround until we properly implement #597
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
