spec_v2: migrate bloom
#19966
spec_v2: migrate bloom
#19966
Conversation
similar utils for layout etc should be added later as needed
alice-i-cecile
added
A-Rendering
| @@ -153,3 +159,9 @@ pub struct ComputePipelineDescriptor { | |||
| /// If this is false, reading from workgroup variables before writing to them will result in garbage values. | |||
| pub zero_initialize_workgroup_memory: bool, | |||
| } | |||
|
|
|||
| fn filling_insert_at<T: Clone>(vec: &mut Vec<T>, index: usize, filler: T, value: T) { | |||
There was a problem hiding this comment.
I'm not sure I understand why this is necessary. Why not just push the target directly in the specializer?
There was a problem hiding this comment.
I think in general we shouldn't have specializers rely on the base descriptor having a certain shape, mostly for composition's sake (doesn't matter so much for this pr). If the statement from the specializer is "I want the 0th color target state to be X", push will fail at that if a previous specializer messed with things.
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
Objective
Testing
bloom_3dexample worksFor reviewers:
Please bikeshed! This is where we start to make patterns for using
spec_v2. Some initial thoughts:Specializer<RenderPipeline>for eachBloomXPipeline, but this ended up making fields likebind_group_layoutinaccessible to resource prep systems. Instead, I've made separate specializer structs and put the caches as fields on their respectivePipelines. Does that seem like a good pattern?GetBaseDescriptorentirely and the Resource derive forSpecializedCache? It seems like it might be an anti-pattern.