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

Sync changes from mozilla-central gfx/wr #3893

Merged
merged 9 commits into from Mar 25, 2020
Merged

Conversation

@moz-gfx
Copy link

moz-gfx commented Mar 25, 2020

No description provided.

bpeersmoz and others added 9 commits Mar 25, 2020
…r=gw

Support hiding slices to better understand what's on which layer,
and to hide UI when not relevant.
Requires using a HTTP server due to cross-scripting.

Differential Revision: https://phabricator.services.mozilla.com/D67963

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/c034bb22ce039bd90289c6ca972b00206b069dfa
…cache. r=gw

We already have a cooldown from texture cache items being deallocated a certain amount of time and frames after their last use so we can deallocate texture arrays as soon as they are completely empty. We do this at the end of the frame to avoid deallocating and reallocating within the frame. It's better to reclaim texture memory this way than run into maybe_reclaim_shared_memory which will throw away everything and cause new allocations on the next frame.

Differential Revision: https://phabricator.services.mozilla.com/D68050

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/cb7a03e737951349193fb99410bb907991f7bc35
The current heuristic in TextureCache::maybe_reclaim_shared_memory pretty much clears the cache every 5 seconds. Clearing the cache is prtty drastic though, because it causes us to re-upload data and reallocate several textures on the next frame. We really only want to do it when the savings are big, which happens less often now that texture array layer count is capped at 16 and that textures are released as soon as they are empty.

This makes us clear the cache less often by augmenting the threshold to 16 megabytes and only considering texture regions that would not be reallocated right away (since we grow some texture arrays more than one region at a time).

Differential Revision: https://phabricator.services.mozilla.com/D68051

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/61582f6d817a401e12c32340873d3d781e6cfaf2
…jrmuizel

The texture array is currently grown layer by layer and we typically get to 3 or 4 layers over several frames by the time we are done loading a simple wikipedia page.

Differential Revision: https://phabricator.services.mozilla.com/D68056

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/167562affb96a1777609f6c6bb6f0a1dab520309
@moz-gfx
Copy link
Author

moz-gfx commented Mar 25, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented Mar 25, 2020

📌 Commit 031268a has been approved by auto

@bors-servo
Copy link
Contributor

bors-servo commented Mar 25, 2020

Testing commit 031268a with merge 42e0c32...

@bors-servo
Copy link
Contributor

bors-servo commented Mar 25, 2020

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: auto
Pushing 42e0c32 to master...

@bors-servo bors-servo merged commit 42e0c32 into servo:master Mar 25, 2020
3 checks passed
3 checks passed
Community-TC (pull_request) TaskGroup: success
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.