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

Commits on Mar 25, 2020

  1. Bug 1605283 - Improve support for invalidation debugging and testing …

    …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
    bpeersmoz authored and moz-gfx committed Mar 25, 2020
  2. Bug 1624565 - Eagerly deallocate empty texture arrays in the texture …

    …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
    nical authored and moz-gfx committed Mar 25, 2020
  3. Bug 1624565 - Avoid clearing the texture cache as often. r=gw

    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
    nical authored and moz-gfx committed Mar 25, 2020
  4. Bug 1624640 - Grow the alpha8 texture array four layers at a time. r=…

    …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
    nical authored and moz-gfx committed Mar 25, 2020
You can’t perform that action at this time.