2024.12 ForeverFPS #3304
2024.12 ForeverFPS #3304
Conversation
github-actions
bot
removed
cmake
python
llcharacter
llwindow
llcommon
llcorehttp
labels
| static void setHandler(const Handler&); | ||
| static void setOutOfMemoryStrings(const std::string& title, const std::string& message); | ||
|
|
||
| // When viewer encounters bad alloc or can't access files try warning user about reasons | ||
| static void showOutOfMemory(); | ||
| static void showMissingFiles(); | ||
| // Genering error | ||
| static void show(const std::string&); | ||
| static void show(const std::string&, S32 error_code = -1); |
There was a problem hiding this comment.
If ERROR_OTHER is the "something else went wrong" code, wouldn't we want ERROR_OTHER to be the default value for show(error_code)?
There was a problem hiding this comment.
At the moment -1 means 'don't create a marker' in case you only need a message. The idea was that LL_ERRS will be creating llerror marker or more likely writing LAST_EXEC_LLERROR_CRASH flag into the marker (but time will tell how it turns out).
I intended to fix llerror marker files separately from new exit states, before the 'review priorities' thing happened.
There was a problem hiding this comment.
May be I should have created a separate createMarkerFile in LLError instead of reusing show().
| ERROR_OTHER = 0, | ||
| ERROR_BAD_ALLOC = 1, | ||
| ERROR_MISSING_FILES = 2, | ||
| } eLastExecEvent; |
There was a problem hiding this comment.
Might be good to add a comment something like: "These are used to select LAST_EXEC_OTHER_CRASH, LAST_EXEC_BAD_ALLOC and LAST_EXEC_MISSING_FILES, respectively, which aren't visible from here."
There was a problem hiding this comment.
Agree, will keep it in mind if I get to continue.
There was a problem hiding this comment.
I probably should have done somthing like ERROR_BAD_ALLOC = 6 instead of using switch.
NOTES Anti-virus false positive report:
|
There was a problem hiding this comment.
ForeverFPS Beta approved
viewer = 7.1.12.12999043440
build = https://github.com/secondlife/viewer/releases/tag/Second_Life_Release%2352a9316-ForeverFPS
cohort = ForeverFPS
desired = 2000
Co-authored-by: Andrey Kleshchev <[email protected]>
Backport tag-release token fix to release/2024.12-ForeverFPS branch
|
Increase cohort size to 3000 |
* A lot of tweaking for water. * Get water much closer to 6.6.17. This won't produce 1:1 results, but it should be much closer to where we once were.
Fix media failing to function on PBR materials (#3445)
* #3507 Add distance haze to water to get us closer to 6.6.17's appearance.
* #3455 Add support for water exclusion surfaces
The actual problem is fetch dumping thousands of callbacks, but this should mitigate the problem
as of = 2025-01-28 for RC deploy
build = https://github.com/secondlife/viewer/releases/tag/Second_Life_Release%2352a9316-ForeverFPS
cohort = ForeverFPS
deployed = https://github.com/secondlife/viewer/releases/tag/Second_Life_Release%2352a9316-ForeverFPS
desired = 3000
relnotes:
Second Life Viewer - ForeverFPS Beta
With this release we are continuing to refine performance and fix crashes. We are monitoring performance metrics broadly and for discrete GPUs with the goal of improving FPS "forever".
A new graphics setting has also been included: Max LOD Resolution. This allows users to limit texture sizes to the selected resolution in order to reduce VRAM load and data consumption.
Some users were experiencing a crash on exit with previous ForeverFPS builds. This should now be resolved, please let us know if you are still crashing while exiting the viewer.
For all Second Life viewers you may file a bug report directly at https://feedback.secondlife.com