Compute shader Interface

[IQuick143]

I've found out that Bevy can't support the use of compute shaders within ECS as of now.

What there is already
The compute_shader_game_of_life.rs example shows how you can run a compute shader on a texture residing on the GPU (correct me if I'm wrong) and how to display it.
The animate_shader.rs example shows how one can pass values using an uniform buffer to a shader. Update: the animate_shader.rs has been changed to use new material API and no longer demonstrates uniform buffers.

What is missing
There is no way that I was able to find, that would allow to retrieve data back from the GPU (through a buffer of mapped memory I presume) back into the ECS world.
The goal would be to be able to do something like the wgpu/hello-compute example.

The problems
What I'm not sure is how to design what the user-facing api for compute shaders should be like as the data needs to be eventually copied back in the ECS world but there are multiple time-frames on which an user might want a GPU computation to run:

• On the same frame - a system in the ECS world would block until it recieved the data from the GPU back - useful due to its simplicity for the user, but might not be optimally performant if the GPU roundtrip takes long.
• In a fixed number of frames - a system expects the result within a limited number of frames (probably on the next frame) - useful because it deals with latency caused by data going back and forth, however there will need to be some sort of tracker which links results back to the dispatches of the compute passes and that blocks when we're getting too far behind schedule
• Whenever - the ECS will run without waiting for the heavy computation - useful for heavy tasks like procedural generation, which don't need to be done in real-time, gives no guarantees on when a task gets finished but avoids all blocks in the game logic

What I'm also wondering is how this will integrate with the render-graph as that seems to be fairly handy when it comes to linking multiple steps of a complicated process but it might not be the greatest idea to tie together logic computation (although on the GPU) with the rendering. (Although someone might want to deliberately use the outputs or inputs of vertex and fragment shaders as inputs to a compute step.)

My use-case is running pixel-perfect collision detection between various sprites by drawing their silhouettes and checking for overlap, I need only collisions between layers not individual entities. As GPU's are already made to handle things on the scale of pixels, I find a compute shader a clear fit, since data for rendering the sprites like transforms should be on the GPU already and I don't mind if the data comes back from the GPU a frame late (as long as I can count on a fixed delay).
Even though I understand that this is probably a very niche application, I think compute shaders are very useful for many other projects.

I'm not very well-versed in the specifics of GPU programming and there might be some problems I'm not aware of with the ECS like scheduling GPU-dependent systems.

Any suggestions for improvement/implementation?

[bjorn3]

Whenever - the ECS will run without waiting for the heavy computation - useful for heavy tasks like procedural generation, which don't need to be done in real-time, gives no guarantees on when a task gets finished but avoids all blocks in the game logic

I think "whenever" is too lax for almost all use cases. On a slow gpu it may never run at all. For procedural generation it is likely important that it will eventually run to prevent for example the user not seeing any terrain at all. I think it wouls be better to say that it runs in idle time whenever possible, but otherwise gets a fixed small percentage of the gpu to ensure forward progress even if slowly.

[IQuick143]

You raise a good point.
There perhaps needs to be some mechanism preventing resource starvation between hungry shaders and other things that need to be done on time. Though that was not exactly what I meant there.

By "whenever" I didn't necessarily mean that the GPU gives it minimal priority, but that the game-loop should not get blocked just because it's taking too long.

[dennisorlando]

Any updates on this? I'm currently looking for a solution to render some pixels using a shader while also getting some calculations back

[tombh]

I think this is covered by the gpu_readback.rs example now?

There's also a crate that wraps all this up in a neat plugin: https://github.com/AnthonyTornetta/bevy_easy_compute