Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using bindgroup other than 0 #6

Open
rYuuk opened this issue Aug 17, 2024 · 6 comments
Open

Using bindgroup other than 0 #6

rYuuk opened this issue Aug 17, 2024 · 6 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@rYuuk
Copy link

rYuuk commented Aug 17, 2024

I am not sure, how to use bind group other than 0 for my compute shader. Is this functionality available?

@group(1) @binding(0)
var<uniform> value: i32;

It seems that by default it goes to 0

let bind_group_layout = pipeline.get_bind_group_layout(0);
      ...
          cpass.set_pipeline(pipeline);
          cpass.set_bind_group(0, &bind_group, &[]);
          cpass.dispatch_workgroups(
              compute_pass.workgroups[0],
              compute_pass.workgroups[1],
              compute_pass.workgroups[2],
          )
      }
@tombh
Copy link

tombh commented Aug 30, 2024

Is it possible that you're confusing bind_group and bind_group_layout? A bind_group_layout doesn't actually contain any data. It's Rust's bind_group[0] that maps to WGSL's @binding(0).

So if we look at the example in the README:

let worker = AppComputeWorkerBuilder::new(world)
    // Add a uniform variable
    .add_uniform("uni", &5.)

    // Add a staging buffer, it will be available from
    // both CPU and GPU land.
    .add_staging("values", &[1., 2., 3., 4.])

    // Create a compute pass from your compute shader
    // and define used variables
    .add_pass::<SimpleShader>([4, 1, 1], &["uni", "values"])
    .build();

Then add_uniform("uni", &5.) maps to:

@group(0) @binding(0)
var<uniform> uni: f32;

And .add_staging("values", &[1., 2., 3., 4.]) maps to:

@group(0) @binding(1)
var<storage, read_write> my_storage: array<f32>;

@rYuuk
Copy link
Author

rYuuk commented Aug 30, 2024

Sorry if it wasn't clear, I meant the @group(0) in wgsl shader and not the binding

@group(0) @binding(0)
var<uniform> uni: f32;
@group(1) @binding(0)
var<storage, read_write> my_storage: array<f32>;

@tombh
Copy link

tombh commented Aug 30, 2024

Ahh yes, I see what you mean. I must say I've never actually used a group, and have to admit I'm not sure what it's for. But anyway, it's set in the first arg here: cpass.set_bind_group(0, &bind_group, &[]); right?

@AnthonyTornetta
Copy link
Owner

@rYuuk What use-case are you trying to solve by not using the default group 0 in your compute shader?

@AnthonyTornetta AnthonyTornetta added the question Further information is requested label Sep 1, 2024
@rYuuk
Copy link
Author

rYuuk commented Sep 2, 2024

@rYuuk What use-case are you trying to solve by not using the default group 0 in your compute shader?

I had a compute shader which calculate height change for vertex, following is small example. So instead using binding index which going till 10 for me I wanted to just change the group to 1 to make it easier manage.

#import "shaders/crater.wgsl"::calculateCraterDepth

@group(0) @binding(0)
var<storage, read> vertices: array<vec3<f32>>;
 
@group(0) @binding(1)
var<storage, read_write> heights: array<f32>;

@compute @workgroup_size(1024)
fn main(@builtin(global_invocation_id) id: vec3<u32>) {
     let index = id.x;
 
     if (index >= num_vertices) {
         return;
     }
     // some other stuff here ... 
     let craterDepth = calculateCraterDepth(vertexPos);
     let finalHeight = 1 + craterDepth + noiseSum;
     heights[index] = finalHeight;
}
@group(1) @binding(0)
var<uniform> num_craters: u32;

@group(1) @binding(1)
var<uniform> rim_steepness: f32;

fn calculateCraterDepth(vertexPos: vec3<f32>) -> f32 {
    var craterHeight: f32 = 0.0;
    
    // some calculation here
    
    retrun craterHeight;
}

@AnthonyTornetta
Copy link
Owner

Ah I understand your usecase. I'm pretty busy right now, so I won't be able to work on this within short order. If you want to make a PR implementing this, I would be happy to review it and merge it in. If you do make a PR, try to avoid creating any breaking changes with the current API.

@AnthonyTornetta AnthonyTornetta added enhancement New feature or request good first issue Good for newcomers and removed question Further information is requested labels Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants