Atlas Linden i found the problem and fixed it. I'll keep doing tests and sending you details later (or i might do a pull request). The fix is simple. 1 line. EDIT: i made a pull request on develop branch.

observeur ResidentCould we get an update on this please LL (or obs if you know?) i heard something about the fix bieng rejected? but dont know why, Atlas Linden if you could share any more with us it would be really appreciated as this bug is a right pain given the performance degredation it causes on Mac. Sure we can turn off AA, but then we have to live with jagged edges :-) (which are definately not good in, for example, photo work), thanks

Frankk Parisi Technically, they rejected my fix because the luminance map which is a framebuffer object was using mipmap generation, which i disabled without noticeable effect, beside "fixing" the AA slow down. But it happens the mipmap generation was intended by the developer. The same issue with mipmap generation happens in other parts of the code such as the one related to the reflection probes. There is also a texture copy operation seems to cause a delay also. (those explaining the periodic gigantic spikes in the frametime). I suspect this is some memory access conflict that causes the slow down in both cases. (as the mipmap generation applies to a relatively small texture and in my own tests, changing parameters wouldn't improve the delay. So I've been studying this for many days, but i had to refocus on my work in SL, because this is what makes me eat ;) I do plan to continue my investigations, with a fresh eye on this, and as for LL developers, i don't know if they have been working on it.

observeur ResidentThanks for the update - your efforts are really appreciated! Atlas Linden Please could you give us an update - the issue status is tracked but surely is a priority for the mac viewer? Thanks

Hi Frankk,

Unfortunately there have been no recent updates towards this issue due to other higher priority bugs.

Future updates to this will either be mentioned here or in the GitHub issue: https://github.com/secondlife/viewer/issues/3828

Dan Linden I identified the origin of this issue. It comes from the new water exclusion feature. (EDIT: it's more complicated than that .. see my next comments) If i revert back to the older pipeline.cpp so before this feature was added, the issue doesn't occur. Now i haven't figured "why" .. but this should give your developers a hint. Also the DOF option seems similarly impacted (same thing : when hdr & emissive is ticked).

Dan Linden I tried to narrow this down. First of all, it's not related to actual "computation", but most probably to the frame buffer mechanisms. Something with llrendertarget bindTarget() and flush() .. seems the driver is "waiting" at some point .. now why only with hdr & emissive options? I first though of something with the pixel formats, but not convinced, as i made different combinations, also made tests without rendering anything, with the same result. So maybe when using hdr & emissive it creates more buffers overall, kinda reaching a driver limit ? ..

in pipeline.cpp / Apply FXAA:

mFXAAMap.bindTarget();

mFXAAMap.clear(GL_COLOR_BUFFER_BIT);

// ... commented rendering calls -> no positive effect

mFXAAMap.flush();

or in doWaterExclusionMask()

mWaterExclusionMask.bindTarget();

glClearColor(1, 1, 1, 1);

mWaterExclusionMask.clear();

// mWaterExclusionPool->render();

mWaterExclusionMask.flush();

glClearColor(0, 0, 0, 0);

If i completely disable doWaterExclusionMask() then FXAA is fine (but it doesn't render water ofc).

If i just comment mWaterExclusionPool->render();, FXAA slowed down (delayed i guess)

I hope those observations would help. I will keep digging int he meantime.

Dan Linden If i comment the call to generateExposure(&mLuminanceMap, &mExposureMap); in LLPipeline::renderFinalize() the performance issue with AA is gone as well.

And same thing, if i only keep the calls to dst->bindTarget(); and Flush(), without rendering anything, the problem is back.

Dan Linden Some additional informations:

In llviewerdisplay.cpp, i measured the duration of those calls : render_ui() and swap(). ( render_ui() calls for gPipeline.renderFinalize(); )

without hdr & emissive :

-> render_ui() : about 1200 microseconds

-> swap() : less than 300 microseconds

without hdr & with AA

-> render_ui() : about 1200 microseconds

-> swap(): about 300 microseconds

with hdr & No AA

-> render_ui() : about 1200 microseconds

-> swap(): about 430 microseconds

with hdr & emissive / AA (fxaa or smaa ..) :

-> render_ui() : 1400 microseconds

-> swap(): 6500 microseconds (6 to 7 ms !)

----------

worth noting (maybe) those warnings in the debug window when changing the graphics settings : "GL Error happens before reading back texture. Error code: 1280" coming from readBackRaw();