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>
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>
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>
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>
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>
346: Add Makefile for shader compilation r=kvark a=HanKruiger
I couldn't find clear instructions on how to compile the shaders in the examples, and had to do some digging. So I added instructions to the README to hopefully save other people's time.
Sidenote: When I compile the shaders as they are now (with my instructions), I end up with different `.spv` shaders with (seemingly) equivalent behaviour. I expect this is due to a different version/environment of `glslang` (see below) but it could be a mistake on my part.
```
> glslangValidator --version
Glslang Version: 8.13.3743
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 13.3743
GLSL Version: 4.60 glslang Khronos. 13.3743
SPIR-V Version 0x00010500, Revision 3
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 8
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100
```
Cheers!
Co-authored-by: Han Kruiger <HanKruiger@users.noreply.github.com>
Add example shader compilation instructions
Arbitrary depth directory wildcard like globs aren't a thing in make wildcards.
Add phony targets as prerequisites of .PHONY
345: Rustify the example's use of Extensions and SamplerDescriptor r=kvark a=cwfitzgerald
Implements https://github.com/gfx-rs/wgpu/pull/696.
This didn't change any content from #338, just interface, but I tested a couple examples and it seems to work okay.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
344: Use the new map-async r=kvark a=kvark
Depends on https://github.com/gfx-rs/wgpu/pull/675
It changes the API of mapping and removes `create_buffer_mapped`.
The new functionality is not implemented in Gecko yet, so this breaks the web target, for now.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
338: Add Extension/Limit Interface r=kvark a=cwfitzgerald
Follow up to https://github.com/gfx-rs/wgpu/pull/690.
This forwards the extension/limit access interface into wgpu-rs.
It appears that the web-sys doesn't actually implement any of the methods we need, so I had them return the defaults. `Device::limits` exists, but it returns `Object` not `GpuLimits`, so doesn't appear usable.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
323: Rename SwapChain::get_next_texture to SwapChain::get_next_frame, and return errors to the user. r=kvark a=AlphaModder
Depends on https://github.com/gfx-rs/wgpu/pull/668.
This creates a new type `SwapChainResult` just for the method.
It also alters the signature of `Context::swap_chain_get_next_texture` to return
```rust
(Option<Self::TextureViewId>, wgt::SwapChainStatus, Self::SwapChainOutputDetail)
```
which is a little ugly but I couldn't think of anything better.
Co-authored-by: AlphaModder <quasiflux@gmail.com>
306: Improve example friendliness: Don't busy-redraw in examples r=kvark a=khoek
Looking around for solid Rust graphics libraries, I was a bit shocked when the `wgpu-rs` examples made my whole X desktop environment in Ubuntu laggy---maximizing/minimizing other windows or moving any of them had very noticeable latency when an example was running.
This almost turned me off, but after playing around I found that this was just because of the
```rust
match event {
event::Event::MainEventsCleared => window.request_redraw(),
...
```
in all of the examples. Trying to add the least code possible I've replaced a `ControlFlow::Poll` with `ControlFlow::WaitUntil(...)` in the event loops and capped the redraws-per-second below 50, which completely solves this problem for me (plus the window resize response on the examples themselves are much improved, etc.).
I was just going for an unintrusive fix---this is by no means a perfect solution, but I think in the worst case it won't be any worse that what was there originally. Plus, I think it will make people like me who try to start by copying an example more likely to stick around in the short term.
Co-authored-by: Keeley Hoek <keeley@hoek.io>
302: Add BufferRange struct for #199 r=kvark a=paulkernfeld
- Use in set_index_buffer
- Use in set_vertex_buffer
- Use in BindingResource
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
272: Force the wasm32 types to match Send / Sync with the native types r=kvark a=kyren
This is potentially a controversial change so this is just a draft to discuss it.
Currently, when building wgpu on wasm32, none of the interface types are Send or Sync, whereas on any other platform they are generally Send and Sync and this can cause a lot of pain, especially in the presence of async.
This PR is the nuclear option: lie and forcibly declare nearly all interface types to be Send or Send + Sync.
I think I understand the situation with proposed wasm32 threading a bit better now, and as of right now at least with my current understanding, it seems to me unlikely that javascript values held by rust could *ever* be sent transparently to another worker. The mechanism that rust apparently will use to implement transparent threading will be to use `SharedArrayBuffer` to share memory between multiple workers. Javascript provides a way for certain (serializable) objects to be shared with with other workers through `worker.postMessage()`, so Javascript has *some* story for sending javascript values to other threads, but only plain rust values that exist solely in the `SharedArrayBuffer` memory are send-able under this scheme. I've looked briefly through some of the wasm proposals like the interface types proposal, but I don't have a good sense if there's any proposed mechanism at all for interface types and threads to interact at all.
If that's true that's really unfortunate because it seems like any thread safe API shared by native and web is doomed to mismatch. This is even more unfortunate because many of the webgpu types in the draft standard are marked as 'Serializable', meaning that they *are* actually safe to send to another worker via `postMessage`, but there does not appear to be a planned way for rust to do this transparently.
I definitely could be misunderstanding the situation though and even if I am understanding it, the situation may have since changed. I also don't know the timing here, I don't know what the eventual timing of wasm32 threading support will be vs webgpu support and interface types support. *Right now* this PR is almost certainly sound, but there's definitely a possible future where it becomes unsound, and even maybe a possible future where it becomes unsound but then could later be made sound again.
Co-authored-by: kyren <kerriganw@gmail.com>
There are several things in this commit:
1) Add `Send` or `Send + Sync` bounds to most of the associated types in `Context`.
2) Force most of the handle types and future types returned by the web backend to be Send / Sync
3) Make `BufferReadMapping` and `BufferWriteMapping` `Send` again on native by
making the associated detail types implement `Send`.
