Add MSAA support to pipelined-rendering

[superdump]

Objective

Add MSAA support to the pipelined-rendering branch.

Solution

This is more complicated than it needs to be as I was working toward supporting
dynamically changing MSAA while running, but the inability to remove / override
slot edges prevented this. I felt as I had done most of the work to make it
work, it was worth leaving in.

[superdump]

I don't really think this is good enough to merge as it is, but I would appreciate some guidance on how to proceed with it so I don't waste time doing unnecessary work.

[superdump]

I added support for removing nodes, node edges, slot edges, and subgraphs. And now dynamically changing MSAA samples works. Run the msaa_pipelined example and press 'm' to toggle between no MSAA single-sample, and 4x MSAA.

[cart]

For the most part I think this is pretty uncontroversial and we'll be able to build on this for whatever the final solution is. I think the biggest missing pieces / open questions are:

1. how to rebuild relevant pipelines as needed (which should eventually be solved by my custom shaders work)
2. whether or not to rebuild the graph or "hack in" the changes inside graph nodes (tbd ... i think its probably safe to start with the current impl. however the machinery is pretty complicated and asking people writing custom nodes to emulate that pattern is a big ask. however i haven't really thought about what "hacked in" msaa would look like.).

I'll probably let this simmer for a bit, but unless we come up with alternatives before 0.6, i think we should roll with this impl.

[cart]

(also we've got to resolve the new merge conflicts that came from breaking out "core_pipeline" into its own crate)

[superdump]

I don't know why check-bans is failing on glam, ndk, and ndk-glue but I haven't touched those.

[cart]

I believe these have been fixed on main. Happy to ignore them for now (bors lets us skip them).

[superdump]

Updated on top of pipelined-rendering again.

[superdump]

Updated on top of pipelined-rendering again.

[superdump]

Note: this is now on top of @cart 's pipeline-specialization branch.

[cart]

So I've thought a lot about MSAA and the complexity around graph edge management (which we've both complained about in the bast). Decided to experiment with moving color attachments and resolve targets into View entities (as a new ViewTarget component). I think it is much cleaner. Curious what your thoughts are:
https://github.com/cart/bevy/tree/msaa

I'll PR it if you're on board.

[superdump]

So I've thought a lot about MSAA and the complexity around graph edge management (which we've both complained about in the bast). Decided to experiment with moving color attachments and resolve targets into View entities (as a new ViewTarget component). I think it is much cleaner. Curious what your thoughts are: https://github.com/cart/bevy/tree/msaa

I'll PR it if you're on board.

Do it! I looked over the commit and it looks good except that you hard coded the msaa samples to 4 when creating the pbr pipeline key, and the example got lost. I find the example really useful for checking it doesn’t panic when changing the msaa sample count on the fly, or raising the window.

I had similar thoughts but didn’t want to conflate changes. ExtractedWindow felt like the wrong place for the sampled colour attachment stuff and i thought it would make more sense to be part of the render target. I like how at some point the code just tells you that it doesn’t make sense. :)

[cart]

Closing in favor of #3042