All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=831311

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=6885a5152a078e4861da5106ca2eaff7c20dec138a0a3559b476dc8ef062e3fc


Bot(s) for this bug's original alert(s):

pixel_xl

how did you bisect it? how do I run these tests? how OS is this running on?

And what does VR have to do with readbacks at all? o_O

This was bisected using the VR bisect script at https://cs.chromium.org/chromium/src/chrome/test/vr/auto_bisect.py (we can't currently run these in the Telemetry lab, so no dashboard bisecting for us). The Pixel XL is running N, specifically N2G47V.

Running these tests yourself will require a Daydream-ready device (Pixel/Pixel XL/Pixel 2/Pixel 2 XL) that's rooted, plus you'll need to do some VR-specific stuff like remove the system VrCore image. Once you have a suitable device, I can ping you with further instructions - the easiest way to remove the system VrCore image is with an internal tool.

As for how this affects VR, I'm not sure. +CC mthiesse@ who might know more?

I think it's an interesting result. Comparing trace before and after, all the "reported by system" metrics (which are the ones that actually matters) are down, mostly. Reported by chrome going in the opposite direction is definitely weird.

Maybe someone can try bisecting for those to make sure it's not some other improvement masking things here, or if things are just totally out of wack.

Traces from bots before and after shows same number of textures in the gpu, but one texture is significantly bigger after. I have no idea how my CL can cause that, given it was supposed to be a no-op change, just removing dead code. I'm not totally convinced this is real.

whoever looking into this needs to reproduce this locally. so if you want me to look, then I definitely need this bit:
> plus you'll need to do some VR-specific stuff

I compared all the memory:chrome:gpu_process:reported_by_os metrics from the test run with the CL and the run with the commit immediately before. There weren't any significant changes, so it looks like the actual memory usage didn't go up?

Yeah, you are right, gpu_process:reported_by_os is stayed the same. It's the browser process reported_by_os that went down, at least in the trace on the bot, which could just be a fluke.

So either there is no real difference, or reported_by_os on this particular device don't include memory used by GPU, which happens on some devices.. seems unlikely for pixel device though.

Either way, something is weird, and someone probably should look.

I'll take this. Would still like Michael's input on whether this could have actually affected something for VR.

I don't see how this could cause a regression, if anything it looks like this should be a win for VR.

VR does encounter this code, we do call SetRootWindow with a differently-sized window that's probably smaller than the actual window side, so we should probably expect a memory usage decrease from not creating the layer while in VR...

Removing Internals>VR component and assigning to Internals>XR