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

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


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

chromium-rel-win10

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14d640bcc40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14d640bcc40000

Increase the number of requested output buffers in DXVAVDA by emircan@chromium.org
https://chromium.googlesource.com/chromium/src/+/29386c651dcc6212f082f901bf12ce51a35a009d

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Memory increase is expected as we are allocating 5 more textures in the initialization of HW H264 decoder. There is roughly 10 MB increase which can correspond to that.

Wait, I thought we didn't expect a memory increase in the zero copy case?

I just checked your benchmarks on the other issue and they showed we went form 482.5 MiB to 483.4 MiB; or a ~0.2% increase. 10mb or 2% is larger than expected.

I can run this locally to see how many decoders and what is the resolution. Tbh, those telemetry tests have many different categories of memory and varies run to run.

I ran the browse_social_facebook test that shows regression locally. I cannot reproduce the memory regression with local release builds, but I collected some info about the test. There are 9 DXVAs built and destroyed with max 4 VDAs alive at a time. They request 1280x720 buffers. Because they are using NV12 as output format, they are requesting 2 of each during initialization[0]. That makes extra 4*2*5=40 1280x720 textures initialized at a time. 1280x720 textures should be ~3.6 MB assuming they are 32bpp[1]. This memory regression shows ~10 MB increase. That is roughly 3 more textures, but I am not sure how we get there.

Re benchmarks in the other issue, I re-ran them and got the same results. There isn't much difference in memory. Also, the same bot running that tulip2.mp4 test is also showing no memory change in that time frame[2].

I can still reduce the extra buffers if you wish, i.e. instead of 5->10, we can go 5->8. I am not sure how this test will be affected though. sandersd@, dalecurtis@ WDYT?

[0] https://cs.chromium.org/chromium/src/media/gpu/windows/dxva_video_decode_accelerator_win.cc?type=cs&q=dxvavideodecode&l=2243
[1] https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/rtc_video_decoder.cc?dr=C&l=319
[2] https://chromeperf.appspot.com/report?sid=e4268830203ed9702168791d60a12be5b05b4650bc63907b49e727ca6d60cbca&start_rev=547383&end_rev=549343

Sounds a lot like  issue 840548 , which was caused by increasing the picture buffer count on Mac.

In that issue, the root cause was that previously uncounted memory (pending output IOSurfaces from the decoder) became counted (GLImage::OnMemoryDump()).

In fact the actual system memory usage went down, for complicated reasons. (c.f. https://chromium-review.googlesource.com/c/chromium/src/+/1053222)

I am not sure how memory is measured for DXVA textures, but it's worth investigating whether the same issue is occurring.

What confuses me here is that media.desktop test does not show a regression whereas the infinite scroll test does. Both create H264 DXVA decoder in the same way. I will dig a bit more into DXVA to understand memory traces.
https://chromeperf.appspot.com/report?sid=e4268830203ed9702168791d60a12be5b05b4650bc63907b49e727ca6d60cbca&start_rev=547383&end_rev=549343