bevyengine / bevyengine/bevy

Use a single pass for main rendering pass to optimize MSAA

Open
#22,515 1 comment 0 reactions 0 assignees View on GitHub
A-Rendering C-Performance D-Domain-Expert D-Modest S-Needs-Benchmarking
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

## What problem does this solve or what need does it fill?

Related to #14672 but this does not talk about msaa writeback. I assume msaa writeback is less necessary in the future.

Current MSAA is inefficient on tile-based renderers as it uses `StoreOp::Store` which writes multisampled attachment back to main memory, wasting a lot of bandwidth. Related Vulkan best practice: https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/performance/msaa

## What prevents `StoreOp::Discard` for MSAA?

For example, in opaque pass we render multisampled texture and resolve it to main texture as expected. However in transparent pass if we do this as before, we will lose the opaque results.

I once considered resolving opaque pass to main texture a, then resolving transparent pass to main texture b, and then blending b onto a. However, this approach is incorrect because materials have various alpha modes so we cannot simply blend two textures.

## What solution would you like?

Merging `Node2d::{MainOpaquePass, MainTransparentPass}` into a single pass.
Merging `Node3d::{MainOpaquePass, MainTransmissivePass, MainTransparentPass}` into a single pass.

Thereby we just need to render with `StoreOp::Discard` and resolve it to main texture. Reducing render passes may also slightly improve performance even without MSAA enabled.

Drawbacks: We lose flexibility and can no longer insert custom nodes between the opaque and transparent passes. But I believe this is quite niche.

## What alternative(s) have you considered?

Leave it as is and don't optimize it.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.