kjolnyr / bevy_app_compute Goto Github PK

Hi and thank you for this library, seems like an amazing addition to the ecosystem!
Is there a way to make the calculated data available to a fragment shader to display the results?

For my specific purposes I would need to avoid copying to the CPU as the computed data is too much to copy every frame.

this is my shader code:

@group(0) @binding(0) var<storage,read> firstArray: array<f32>;
@group(0) @binding(1) var<storage,read> secondArray: array<f32>;
@group(0) @binding(2) var<storage,read_write> resultArray: array<f32>;

@compute @workgroup_size(1, 1, 1)
fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
    let index: u32 = global_id.x;

    resultArray[index] = firstArray[index] + secondArray[index];
}

and the code in bevy:

fn calc_gpu_things(mut compute_worker: ResMut<AppComputeWorker<SimpleComputeWorker>>) {
    if !compute_worker.ready() {
        return;
    };

    compute_worker.write_slice("firstArray", &[2.0, 3.0, 5.0, 6.0]);
    //compute_worker.write("secondArray", &[2.0, 3.0, 4.0, 5.0]);
    let result: [f32; 4] = compute_worker.read("resultArray");

    println!("got {:?}", result);
}

#[derive(TypeUuid)]
#[uuid = "2545ae14-a9bc-4f03-9ea4-4eb43d1075a7"]
struct SimpleShader;

impl ComputeShader for SimpleShader {
    fn shader() -> ShaderRef {
        "compute1.wgsl".into()
    }
}

#[derive(Resource)]
struct SimpleComputeWorker;

impl ComputeWorker for SimpleComputeWorker {
    fn build(world: &mut World) -> AppComputeWorker<Self> {
        let worker = AppComputeWorkerBuilder::new(world)
            // Add a staging buffer, it will be available from
            // both CPU and GPU land.
            .add_staging("firstArray", &[2.0, 3.0, 4.0, 5.0])
            .add_staging("secondArray", &[2.0, 3.0, 4.0, 5.0])
            .add_staging("resultArray", &[0.0, 0.0, 0.0, 0.0])
            // Create a compute pass from your compute shader
            // and define used variables
            .add_pass::<SimpleShader>([4, 1, 1], &["firstArray", "secondArray", "resultArray"])
            .build();

        worker
    }
}

and the panic i get during run time:

thread 'Compute Task Pool (4)' panicked at C:\Users\bramb\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.2\src\backend\direct.rs:3056:5:
wgpu error: Validation Error

Caused by:
    In Queue::write_buffer
    Copy of 0..32 would end up overrunning the bounds of the Destination buffer of size 16

Hi,

I need to keep the data on GPU, essentially to compute a uniform buffer that can be shared across workers and used in shaders. is there a way to do that here ?

Best regards

is there a way to use a texture as staging buffer?

i get this error and i have no idea where it could be coming from

thread 'Compute Task Pool (7)' panicked at C:\Users\bramb.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.2\src\backend\direct.rs:1729:13:
Error reflecting bind group 0: Invalid group index 0

any info / help would be awesome :)

I've been so busy since I started this project that I can't find the time to work on it regularily.

This crate is quite useful for niche scenarios so I believe it should carry on living without me.

If you are willing to maintain it, please contact me.

Hi :)
I'm wondering if you could write a simple game of life example in order to show how to integrate a compute shader, built using this plugin, with bevy's traditional textures.

My goal is to write a compute shader which modifies an entity's texture while also computing some values. A "Game of life" example would pretty much solve the "reading and writing a texture" part, which would be amazing.

I'm aware that this request exists just because I'm not able to do it myself :...)

So I think I got a working solution for #2, but in order to demonstrate it I decided to try porting over the Game of Life example from Bevy. And ran into another problem. That example actually has two passes in it, an init pass and an update pass. The init pass needs to run first, and only once. This library supports running once, but only for the whole worker, not just one pass. It's not hard to port the Game of Life init pass onto the CPU, but I think this still exposed a need.

In my own project, I also have reason to want to run some passes a set number of times.

So I'm not sure exactly what the API and internal structure should look like, but clearly there's value in having more fine-grained control over how things run.