You shouldn't be allowed to mix and match a compute/render pass/pipelines. Moreover, a Context will never have any meaning without an accompanying pass to work on. So to avoid a lot of small cuts, the render pass should be merged into the Context.
There are probably a couple options to do this.
- We can expose the type of the
Context to allow Context::new(). - A
context can have a setter function which sets the pass of the context and makes it part of the type. - I can accept a render/compute pass in
eager_binding! - Instead of setting
context to some Context, I could instead set context to a closure that looks like |rpass| { Context{rpass} }
You shouldn't be allowed to mix and match a compute/render pass/pipelines. Moreover, a Context will never have any meaning without an accompanying pass to work on. So to avoid a lot of small cuts, the render pass should be merged into the Context.
There are probably a couple options to do this.
Contextto allowContext::new().contextcan have a setter function which sets the pass of the context and makes it part of the type.eager_binding!contextto someContext, I could instead setcontextto a closure that looks like|rpass| { Context{rpass} }