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

LRU-style Texture Memory Management #301

Merged
merged 2 commits into from
Jun 26, 2024
Merged

Conversation

frank-weindel
Copy link
Collaborator

@frank-weindel frank-weindel commented Jun 17, 2024

MemMonitor.mov
  • See TSDoc comments for TextureMemoryManagerSettings for info on the new configuration settings.
  • Adds monitor boolean URL param to examples that shows a memory monitor.
  • Replaced the term "Texture Garbage Collection" with "Texture Cleanup" to reduce confusion with the Browser/JavaScript's garbage collection process.

Resolves #233

BREAKING CHANGE

@frank-weindel frank-weindel added the breaking change! This issue / PR may require downstream dependencies to make changes to retain existing functionality label Jun 17, 2024
@frank-weindel
Copy link
Collaborator Author

@elsassph Hoping to get your take on this approach. I believe it aligns with what you were discussing in #233. I'm calling it LRU since it frees textures that are least recently used (older) first.

const { inverseKeyCache, keyCache } = this;
const cacheKey = inverseKeyCache.get(texture);
if (cacheKey) {
inverseKeyCache.delete(texture);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably don't need to clear WeakMap entries

if (!isIdle) {
stage.emit('idle');
if (stage.txMemManager.checkCleanup()) {
Copy link
Contributor

@elsassph elsassph Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit concerned with this approach:

  • with L2, texture cleanup would usually happen only reaching the critical level, so scrolling down then up a screen full of rails will only have visible textures reloading after we hit the ceiling (possibly never),
  • with L3 it will tend to cleanup both when reaching critical level AND every X seconds (&idle), which means it will effectively feel like the device has only a fraction of the GPU texture capacity. I appreciate the delay is configurable, but 5s default seem aggressive.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new L3 approach here is also only freeing down to the Target Threshold (in LRU order) instead of all non-renderable textures. It actually shouldn't run on idle if the memory use is lower than the Target Threshold. I forgot to add a check for that.

To emulate L2 behavior, I think you could set the Target Threshold to 0 and Cleanup Interval to Infinity. But the sorting by LRU would be pointless in that case.

How does this approach compare to what you were hoping for in #233?

Copy link
Contributor

@elsassph elsassph Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's certainly going to enable what we were "hacking" with L2 - that's great to see!

Just saying that the default 5s, while it can be changed, is probably too frequent: for most apps it will divide the effective memory pressure and defeat the point of caching.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've increased the default to 30 seconds. I really don't have a sense of what it should be. But we can adjust in the future as needed.

@frank-weindel frank-weindel linked an issue Jun 21, 2024 that may be closed by this pull request
- Adds `monitor` boolean URL param to examples that shows a memory monitor.

Resolves #233

BREAKING CHANGE
- Raise default cleanupInterval to 30 seconds
- Add check to not run Idle Cleanup if Target Threshold is not exceeded
- Remove unnecessary delete from WeakMap
@frank-weindel frank-weindel merged commit ae5f6a6 into dev Jun 26, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change! This issue / PR may require downstream dependencies to make changes to retain existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature: granular memory management
4 participants