Introduce structure interner, and use for clip interning. #3075

gw3583 · 2018-09-18T08:41:05Z

This patch introduces a new data structure, that allows generic
structures to be interned. This works similarly to how normal
string interning works, however it is specialized to the
thread model for WR (explained at the top of intern.rs).

The effect of this change is that clip nodes are de-duplicated
and persisted between both frames and display lists.

This has three primary benefits:

Since they are de-duplicated, the handle for an interned
structure uniquely identifies it. This is very useful for
future use where we want to be able to quickly and cheaply
compare if the contents of a cached picture matches that
of a new display list.
Since they are persisted between display lists, the GPU
cache handles for the nodes remain valid. This means far
fewer GPU cache update patches for types that are interned.
Since they are de-duplicated by content hash value, there
are fewer clips overall used by the frame builder.

The plan in the future is to extend this to other primitive types,
as well as gradient stops, text runs etc. This will allow us to
very quickly check if a cached picture remains valid, even in the
presence of a completely new display list.

This adds a small amount of overhead to the scene builder thread,
(extra hashing) but reduces the CPU time in the render backend and
compositor threads, which is also a good tradeoff.

This change is

gw3583 · 2018-09-18T08:41:37Z

r? @kvark

This does seem to give a noticeable reduction in the number of GPU cache rows on several pages that I tested on. Of course, the major wins wouldn't come until we use it for more than just clips.

The main remaining bit of work (apart from review comments) is that I haven't hooked up the interner and data store to the capture / replay code yet.

Try run looks good:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=32256ade54c961eabec197c380bb2eeda194f8d1&selectedJob=199879097

(lots of blue and orange, but they are unrelated as far as I can tell - still some jobs pending though)

gw3583 · 2018-09-18T08:42:15Z

And also r? @nical too, since this touches scene builder thread and such things.

nical

Looks good to me, just want to make sure this doesn't interfere with my world domination plans concerning the hit tester, see comment.

nical · 2018-09-18T09:37:30Z

webrender/src/render_backend.rs

            );
-            self.hit_tester = Some(frame_builder.create_hit_tester(&self.clip_scroll_tree));
+            self.hit_tester = Some(frame_builder.create_hit_tester(


My only worry is creating a dependency between frame building and building the hit tester. We really need to be able to build the latter independently. Here we are first mutably passing the clip data store to the frame builder and then using it to build the hit tester.
Upon inspecting the code that mutates the data store, it looks like only GPU thingies are modified so it should be safe to create the hit tester independently, but I'd feel better if we moved the line that creates the hit tester above the FrameBuilder::build call to make sure dependencies don't creep in.

Yep, sounds good.

nical · 2018-09-18T09:37:30Z

webrender/src/intern.rs

+pub struct Interner<S : Eq + Hash + Clone + Debug, M> {
+    // Uniquely map an interning key to a handle
+    map: FastHashMap<S, Handle<M>>,
+    // List of free slots in the data store for re-used.


nit: "for re-use"?

kvark

Reviewed 17 of 17 files at r1.
Reviewable status: all files reviewed, 19 unresolved discussions (waiting on @nical and @gw3583)

webrender/src/batch.rs, line 1778 at r1 (raw file):

        clip_scroll_tree: &ClipScrollTree,
        transforms: &mut TransformPalette,
        clip_data_store: &ClipDataStore,

does it make sense to merge clip_data_store and clip_store?

webrender/src/clip.rs, line 743 at r1 (raw file):

// comparison of clip node equality by handle, and also allows
// the uploaded GPU cache handle to be retained between display lists.
// TODO(gw): Maybe we should consider constructing these directly

perhaps, this would let us not have both Au and non-Au versions of the clip structs

webrender/src/clip.rs, line 748 at r1 (raw file):

#[cfg_attr(feature = "capture", derive(Serialize))]
#[cfg_attr(feature = "replay", derive(Deserialize))]
pub enum ClipItemKey {

I agree that names are missing here

webrender/src/clip.rs, line 835 at r1 (raw file):

#[cfg_attr(feature = "capture", derive(Serialize))]
#[cfg_attr(feature = "replay", derive(Deserialize))]
pub enum ClipItem {

I do wonder if we can make this more generic, i.e. just have <T> all the way down, where T=Au or T=f32 depending on the requirements?

webrender/src/intern.rs, line 36 at r1 (raw file):

 is no longer referencing.

 Items in the data store are stored in a traditional

one way to use a freelist here is to have it built into Item<T> like this:

enum Item<T> {
  Valid { epoch: Epoch, data: T },
  Free { next: usize },
}

We could easily hide the enumeration tag by using NonZeroU64:

struct Epoch(NonZeroU64);

This way we'd also not need the INVALID, I think.

Perhaps, this approach would improve data locality and make the code more idiomatic/typed?

webrender/src/intern.rs, line 45 at r1 (raw file):

#[cfg_attr(feature = "replay", derive(Deserialize))]
#[derive(Debug, Copy, Clone, PartialEq)]
struct Epoch(u64);

let's document what the epoch applies to: scene builder, individual interned item, etc

webrender/src/intern.rs, line 84 at r1 (raw file):

}

// The data item is stored with an epoch, for validating

let's have all those internal comments as doc comments (///), now that cargo doc is able to produce private documentation that would be useful

webrender/src/intern.rs, line 100 at r1 (raw file):

    items: Vec<Item<T>>,
    _source: PhantomData<S>,
    _marker: PhantomData<M>,

what is the marker for?

webrender/src/intern.rs, line 126 at r1 (raw file):

                        epoch: update_list.epoch,
                    };
                    if self.items.len() == update.index {

what is guaranteeing that the index isn't greater than the length?

webrender/src/intern.rs, line 143 at r1 (raw file):

    // Retrieve an item from the store via handle
    pub fn get(&self, handle: &Handle<M>) -> &T {

nit: consider impl ops::Index

webrender/src/intern.rs, line 174 at r1 (raw file):

    updates: Vec<Update<S>>,
    // The current epoch for the interner.
    current_epoch: Epoch,

that's quite a few epochs, epochs everywhere!

webrender/src/intern.rs, line 195 at r1 (raw file):

    pub fn intern(
        &mut self,
        data: &S,

if data here is the same as on the data store side, let's use the same generic T for it to avoid confusion

webrender/src/intern.rs, line 254 at r1 (raw file):

        let current_epoch = self.current_epoch.0;

        // First, run a GC step. Walk through the handles, and

do we really need the "used for some time" semantics here? I thought just removing ones not used for each incoming scene build would be sufficient.

webrender/src/intern.rs, line 284 at r1 (raw file):

        // Begin the next epoch
        self.current_epoch = Epoch(self.current_epoch.0 + 1);

the method itself does much more than just getting the updates, so we should probably rename it to something other than get_updates in order to indicate that we are bumping the epoch and GC-cleaning

webrender/src/intern.rs, line 284 at r1 (raw file):

        // Begin the next epoch
        self.current_epoch = Epoch(self.current_epoch.0 + 1);

hm, I am worried a bit that the interner keeps its own epoch. Why isn't the epoch really driven by the scene builder, so that one build = one epoch?

webrender/src/render_backend.rs, line 1305 at r1 (raw file):

            }

            // TODO(gw): Work out serializing the clip interner / store.

isn't this done already?

webrender_api/src/units.rs, line 222 at r1 (raw file):

}

pub trait AuRectHelpers {

we have 4 traits that could pretty much be trait AuHelpers<T>

gw3583

Reviewable status: 8 of 17 files reviewed, 17 unresolved discussions (waiting on @kvark, @nical, and @gw3583)

webrender/src/batch.rs, line 1778 at r1 (raw file):