148: Change Queue::submit to take &self r=kvark a=LaylConway
This small change allows multiple threads to submit buffers slightly more efficiently, by being able to do it concurrently without a lock on Queue.
In practice currently `Queue::submit` does a lot of locking internally for most of the function's duration, so it's only a small performance win right now, but it opens up the road for more improvements.
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
Updates for boids example
Rename example folder
Use chunks_muts when creating initial_particles data
No need for depth
Syntax and minor changes
calculate multiple particles in single compute unit
updates boids example to use framework impl
removed code
fix gpu invocations constants
145: Mark CommandEncoder as !Send !Sync r=kvark a=LaylConway
These depend on the thread-specific command pool they're allocated from, which requires only one thread accessing them at a time, so they can't be moved to other threads without additional synchronization.
Co-authored-by: Layl <2385329-layl@users.noreply.gitlab.com>
120: prototype of futures for buffer mapping r=grovesNL a=swiftcoder
This is largely in request-for-comment state right now, although it does work.
As written the `GpuFuture` implementation only works with types that are `Copy`, which rules out using a destructor to unmap the buffer. I'm assume it's possible to write a future type that can produce a non-Copy result, but I haven't sufficiently internalised how `Pin` works to see how.
Co-authored-by: Tristam MacDonald <swiftcoder@gmail.com>
127: Use u8 for buffer mapping r=kvark a=Coder-256
cc @kvark @grovesNL
This is a temporary solution for #119, and a follow-up for #126.
Co-authored-by: Jacob Greenfield <jacob@jacobgreenfield.me>
126: Fix generic bounds on buffer mapping r=grovesNL a=kvark
Smaller (and incomplete!) alternative to #119 while it's still discussed.
One missing piece here is alignment. cc @Coder-256
Also, importing `wgpu-core` as just "core" wasn't the best idea 😅 : it collides with the actual `core`.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
115: Handle error case for SwapChain::get_next_texture r=kvark a=antonok-edm
Updates `SwapChain::get_next_texture` to account for https://github.com/gfx-rs/wgpu/pull/369. Otherwise, an invalid `Id` is returned and may cause confusing errors.
Co-authored-by: Anton Lazarev <antonok35@gmail.com>
109: add initial skybox example, ref #93 r=m4b a=m4b
1. doesn't render the images at all
2. mip map stuff needs clarification
3. will update uniform with temporal rotation so we can see the skybox better
Co-authored-by: m4b <m4b.github.com@gmail.com>
98: Add pixels to the friends list r=kvark a=parasyte
We're using `wgpu` to create the world's most powerful pixel frame buffer. 😂
The crate isn't published yet. Waiting for `wgpu` 0.4: https://github.com/parasyte/pixels/issues/16
Co-authored-by: Jay Oster <jay@kodewerx.org>
92: Fix docs describing how to create a surface r=grovesNL a=parasyte
I noticed this issue as I was combing the source.
Co-authored-by: Jay Oster <jay@kodewerx.org>
89: Adapter::get_info r=kvark a=paulkernfeld
This more or less addresses #7.
If the example is too trivial, I'm happy to remove it.
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
