Renderable buffers

[tombh]

Some changes needed to be able to directly use the results of compute work in a render pass.

• Make worker.buffers public so that the buffers can be used in bind groups in the Render World.
• Adds a new builder method: builder.set_extra_buffer_usages(usages: Option<BufferUsages>)

I'm not sure if this is the best approach, it's just the first idea that came to me.

[AnthonyTornetta]

@tombh Could you elaborate on how this would be used in conjunction with the render pass? I haven't tried to do that before, so your input would be very helpful to me understanding how this would be used.

[tombh]

So let's consider the current boids example in this repo. We spawn MaterialMesh2dBundle for every boid, which firstly gets its position data from the GPU compute worker, and then secondly reuploads the meshes to the GPU for rendering.

It would of course save a lot of back and forth if the render pass could just call into an existing GPU buffer to get position data. This is not currently possible for 2 reasons:

1. Buffers are private to the plugin, so there's no way of passing a compute worker buffer to the render pass.
2. Buffers have fixed usages. For a buffer to be a source of position data in a render pass it needs at least the usage, BufferUsage::VERTEX and perhaps even BufferUsage::FRAGMENT.

Like I said I've no idea if this PR is a sane approach, it was just the first idea that came to me.

[AnthonyTornetta]

I do believe this does have some good usecases, so I'm happy to pull this in! This seems like a simple approach to this problem, so I'm happy with the implementation. I'd like to do some testing before merging this in, and get your feedback on one change request first though.

[tombh]

I've also added a new example to demonstrate the benefits of the changes. See the Game of Life example. It can simulate 1.5 million cells at 60fps on my integrated GPU.

I also fixed the Boids example, so that the boids actually flock now.

[tombh]

The tests failed because of a change in nightly Clippy. What do you think about pinning CI to a specific version of Rust? That way we get to decide when breaking changes to CI runs might happen. Or we could add a stable version to the Github Action's matrix, and only failures in that can fail the CI build. Failures on the nightly toolchain could show up as red in the CI run but wouldn't actually create an overall CI failure.

[AnthonyTornetta]

I'm a huge fan of this PR! The examples you provided were a great showcase of their benefits - I'll be making a new release of this package shortly and including this! Thank you for your great work on this!

I set the CI to use nightly rust because I run nightly on my machine, and I don't want anyone that's running nightly to get clippy errors on their local machine that aren't caught by the CI.

[tombh]

Thanks!