bjornbytes
Better Multisampled Textures/Resolves
Currently multisampled Textures ({ samples = 4 } flag) aren't super great. You can render to them by using them as a canvas in a pass, but after that you're kinda stuck. There isn't really a way to resolve the texture, and you can't sample from it normally. The only thing you can maybe do is send it to a texture2DMS shader variable and do a manual resolve. This should be improved somehow.
Also, a render pass that uses a LOAD load op with an internal MSAA texture will clear instead right now, because there isn't an easy way to load the single-sampled texture contents into the MSAA render target. This should either be A) documented B) fixed C) an error.
"Pass stitching" is the idea that lovr could merge render passes if they render to the same attachments. It's kind of like a special case of a render graph. It would allow for multisampled attachments to use clear=false in some situations. I lean towards not doing this though because the implementation/documentation is too complicated.
Could do the thing where msaa textures have a lazily-resolved single-sample copy of themselves. Also transfers and (non-msaa?) storage writes wouldn't be allowed on msaa textures. That way the msaa version of the texture is the source of truth and you can always use clear=false with it and also use it in materials/resources reliably. I think clear=false would still be forbidden if you're using "automatic" multisampling (samples=4 on the canvas instead of using msaa textures as the attachments), because the multisampled textures don't really exist in that case and can't be loaded from. You'd need to use an msaa texture for that (and incur a bandwidth penalty on mobile).
Multisampled textures were removed in #748, see that PR for more discussion about a future API that adds them back.