Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSAO only samples mip 0 leading to worse than expected performance. #11222

Closed
Elabajaba opened this issue Jan 5, 2024 · 0 comments · Fixed by #11292
Closed

SSAO only samples mip 0 leading to worse than expected performance. #11222

Elabajaba opened this issue Jan 5, 2024 · 0 comments · Fixed by #11292
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times P-High This is particularly urgent, and deserves immediate attention
Milestone

Comments

@Elabajaba
Copy link
Contributor

Elabajaba commented Jan 5, 2024

Bevy version

0.12/main/probably every version since ssao was added

Relevant system information

AdapterInfo { name: "AMD Radeon RX 6800 XT", vendor: 4098, device: 29631, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "22.11.2", backend: Vulkan }

Also happens on dx12.

What you did

Add SSAO to a scene or run the ssao example, profile it with radeon gpu profiler to see how long the ssao passes take, compare performance with the XeGTAO sample it's based on (https://github.com/GameTechDev/XeGTAO), then spend a few days trying to figure out why bevy's is so much slower.

What went wrong

This line always gives a negative mip value because the samples are all between 0..1 (and thus the length of the samples has a negative log2 value), which causes it to be clamped to 0.0 so we're always sampling mip 0 which has a huge performance impact.

XeGTAO uses a "working depth buffer" that seems to have a range of 0-10000, with the closest thing in the demo scene being ~1.4.

Additional information

Simply multiplying the sample on that line by 10000 doesn't really appear to have a visual effect in static scenes (but improves performance from 3.2ms to 1ms for the main SSAO pass on my gpu at 4k), but in the ssao example it artifacts pretty badly.

I believe the fix for the artifacting is to improve the denoiser (eg. by just copying the xegtao one).

Turns out it's using pixel space to calculate the mip level, so we need to multiply by the resolution instead of a magical 10000 value.

Ssao.mp4
@Elabajaba Elabajaba added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Jan 5, 2024
@JMS55 JMS55 added this to the 0.13 milestone Jan 5, 2024
@JMS55 JMS55 added A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times and removed S-Needs-Triage This issue needs to be labelled labels Jan 5, 2024
@alice-i-cecile alice-i-cecile added the P-High This is particularly urgent, and deserves immediate attention label Jan 7, 2024
github-merge-queue bot pushed a commit that referenced this issue Jan 12, 2024
# Objective

Fixes #11222

## Solution

SSAO's sample_mip_level was always giving negative values because it was
in UV space (0..1) when it needed to be in pixel units (0..resolution).

Fixing it so it properly samples lower mip levels when appropriate is a
pretty large speedup (~3.2ms -> ~1ms at 4k, ~507us-> 256us at 1080p on a
6800xt), and I didn't notice any obvious visual quality differences.

---------

Co-authored-by: Alice Cecile <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times P-High This is particularly urgent, and deserves immediate attention
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants