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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZy4QELEhNTdG9wcGFnZUFsZXJ0UGFyZW50IrIBQ2hyb21pdW1QZXJmL2Nocm9taXVtLXJlbC13aW43LWdwdS1udmlkaWEvc3lzdGVtX2hlYWx0aC5tZW1vcnlfZGVza3RvcC9tZW1vcnk6Y2hyb21lOmFsbF9wcm9jZXNzZXM6cmVwb3J0ZWRfYnlfY2hyb21lOnNoYXJlZGJpdG1hcDplZmZlY3RpdmVfc2l6ZV9hdmcvbG9hZF9nYW1lcy9sb2FkX2dhbWVzX2xhem9ycwwLEg1TdG9wcGFnZUFsZXJ0GLz4GAw


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

chromium-rel-win7-gpu-nvidia

Last trace with the data: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_22-2016-07-29_09-56-02-45667.html
First trace without the data: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_22-2016-07-29_12-06-01-98838.html

Last build with the data: https://build.chromium.org/p/chromium.perf/builders/Win%207%20Nvidia%20GPU%20Perf%20%283%29/builds/5258
First build without the data: https://build.chromium.org/p/chromium.perf/builders/Win%207%20Nvidia%20GPU%20Perf%20%283%29/builds/5259

The value actually started being flakily (not) reported since build
5201:

             ^ ...
    REPORTED | 5199
             v 5200
             ^ 5201
NOT reported | ...
             v 5217
    REPORTED * 5218
             ^ 5219
NOT reported | ...
             v 5226
    REPORTED * 5227
             ^ 5228
NOT reported | ...
             v 5257
    REPORTED * 5258
             ^ 5259
NOT reported | ...
             v

Whenever the value *is* reported, the total size of sharedbitmap in the
browser is *always* 96 KiB and the total effective size is 0 KiB.

ericrk: Is this behavior expected, or does it seem like a genuine bug to
you?

There's a similar situation with gpumemory buffer (at various
revisions):

https://chromeperf.appspot.com/report?sid=b44fc22455166fca5a910548edae8c14dd1ea4d313fbb4fc8dfca179449c4490&rev=406258
https://chromeperf.appspot.com/report?sid=f24cb8572add5db8af9cf9c1f5e18b7f05a9bf706af94b7fec7c1aa7c6c749e4&rev=406249
https://chromeperf.appspot.com/report?sid=76f455cb1135f1ca5ea1406b772f869fd9ab951b5869f9de120940892d4c3647&rev=408362
https://chromeperf.appspot.com/report?sid=6f45434e06bd89726f5cb91da5e549626f3c77d6468e0ea1bed16ad9fff48e5f&rev=406775
https://chromeperf.appspot.com/report?sid=14b4443dc37db7c08a8e2037f4ceff3d23ab171b7c0a1c02226418896d634acd&rev=406775
https://chromeperf.appspot.com/report?sid=6ff46963009ae6aeb5e4ca3299e9c7f43afb9d638bcc26273f9a5d6c359e427a&rev=407364

ericrk@ Could you please comment on #2?

This looks fine to me:

We don't expect heavy usage of SharedBitmaps on Windows - it appears the browser is creating one (not sure why it would, but also no reason it wouldn't, the numbers line up with resource providers in the browser proc).

We also expect minimal use of GPU Memory Buffers - these are only used to upload textures and are automatically deleted after 1s of non-use. It's very possible that most of the GPU memory buffers have been dropped before the measurement runs, especially on pages that aren't doing constant raster.

Overall, this doesn't seem concerning to me. Adding a (longer?) wait before taking memory measurements will likely eliminate the GPU Memory Buffer noise.