Skip to content

AA Slowing down the viewer on Mac FIX #3889

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

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

mobserveur
Copy link
Contributor

AA was causing the viewer to slow down when used with hdr & emissive option ON. This commit fixes the issue, by making sure mipmap generation is inactive on the Luminance framebuffer.

@github-actions github-actions bot added the c/cpp label Apr 8, 2025
Copy link

github-actions bot commented Apr 8, 2025

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

AA was causing the viewer to slow down when used with hdr & emissive option ON.
This commit fixes the issue, by making sure mipmap generation is inactive on the Luminance framebuffer.
@AtlasLinden AtlasLinden linked an issue Apr 8, 2025 that may be closed by this pull request
@Geenz
Copy link
Collaborator

Geenz commented Apr 15, 2025

Thanks @mobserveur for the contrib!

So there's one glaring problem with this - and that's we do actually use a mipmap from the luminance map.

Specifically when we generate the exposure map, we bind the luminance map to the emissive uniform (line 7116). The exposure generation shader (exposureF.glsl) uses it like this:

    float L = textureLod(emissiveRect, tc, 8).r;
                                        // ^ the mip in question

What would be a better approach is to instead just reduce the resolution of the luminance map since we only ever really use it here, and at a much higher mip. In this context, being a 256x256 texture, mipmap 8 is going to be 1x1.

@mobserveur
Copy link
Contributor Author

Thanks @mobserveur for the contrib!

So there's one glaring problem with this - and that's we do actually use a mipmap from the luminance map.

Specifically when we generate the exposure map, we bind the luminance map to the emissive uniform (line 7116). The exposure generation shader (exposureF.glsl) uses it like this:

    float L = textureLod(emissiveRect, tc, 8).r;
                                        // ^ the mip in question

What would be a better approach is to instead just reduce the resolution of the luminance map since we only ever really use it here, and at a much higher mip. In this context, being a 256x256 texture, mipmap 8 is going to be 1x1.

I understand. I did actually notice frametime spikes related to exposure and luminance in my own tests, sometimes .. after the "fix" has been applied. It did fix the slow down but those spikes were appearing. So i understand the reason now. I wonder why this mipmap generation was causing the issue though. I will investigate on my side too, trying to understand what's going on. Also i posted an other feedback on the canny, this might very well be related somehow : https://feedback.secondlife.com/bug-reports/p/regular-and-high-frametime-spikes-on-mac

@Geenz Geenz requested a review from Copilot April 18, 2025 00:02
Copilot

This comment was marked as resolved.

@Geenz
Copy link
Collaborator

Geenz commented Apr 28, 2025

@mobserveur Since it seems there needs to be more investigation around this - I'm gonna move this into a draft PR.

@Geenz Geenz marked this pull request as draft April 28, 2025 21:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mac: FXAA/SMAA Severe Performance issue
2 participants