Kjolnyr
A texture as staging buffer
Hello, I'm not sure why you would want a texture as staging buffer, can you elaborate?
i'm trying to render using a raymarcher i created directly to a texture ( like the game of life from bevy which renders the results directly to a texture : Game of Life ) actualy i think your library will make the Game of Life exemple far less boilerplate. but it will need to output the computation result to a texture.
Right now I focused my crate on doing computation on the GPU without caring about the render part, think nVidia's CUDA. Though I'd love to add support for texture buffers! I'll work on that in my free time, but if you feel like opening a PR for this, you're welcome!
I actually care about this as well. And looking through the code, I don't understand it super well yet but it's looking like it'd be fairly simple to add. It appears AppComputeWorker::dispatch sets up the bind group, and it just uses whatever buffer is provided. If that buffer points to a texture, it'll just work, right? Which means the only change required would be adding a new function like AppComputeWorkerBuilder::add_texture to add a texture buffer, right? It'd probably take a Handle<Image> as the argument.
If this sounds right to you, I'll happily make a PR for it.
Okay, this is a bit more complicated than I'd originally thought, and is requiring a deeper dive, but I should still be able to manage it.
Textures are not backed by the same sort of buffer. The buffer or texture is assigned to the binding group entry as a BindingResource, which is an enum with many variants, two of which are Buffer and TextureView. So the buffers being used now are a BindingResource::Buffer (which you get from Buffer::as_enitre_binding) and the textures will need to be a BindingResource::TextureView. And the BindingResource is intended to be a temporary struct, and has lifestyle notations to enforce that, so we can't just choose to store that instead of a Buffer.
I think we need to instead make a new enum which stores a Buffer or a Handle<Image>. Then we need to get Res<RenderAssets<Image>> to extract a GpuImage using the handle, and get the TextureView from that, which goes into the BindingResource::TextureView, as done in the Bevy Game of Life example.
And there's probably some thought needed for how the textures interact with the various read/write methods on AppComputeWorker. If the API consumer is providing a Handle<Image>, then they have access to the texture already, so we probably don't need read/write methods for accessing textures. So I'm thinking the read/write methods should just fail when called on a texture.
Hi - is there any movement on this? The compute shader example (game of life) for Bevy is so convoluted I can't see myself using Bevy without this plugin. This library looks like exactly what I need - but without any suport for storage textures it seems very limited - or am I missing something?
I worked on it a bit, and ran into a number of complications. I'm sure they're all solvable, but it was becoming such a deep dive that I eventually decided it wasn't worth my time, and switched over to just building off the Game of Life example instead.