Issue 391646 in chromium: tab spinner ridiculously taxes the GPU

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Cr-UI Pri-2 Via-Wizard Type-Bug OS-Linux

New issue 391646 by pdknsk: tab spinner ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/36.0.1985.103 Safari/537.36

Steps to reproduce the problem:
1. http://wait100s.appspot.com

What is the expected behavior?
CPU and GPU load remains low while the tab spins.

What went wrong?
The fan drastically increases RPM, suggesting high load. CPU load is low,
but GPU load is very high.

Did this work before? Yes pre-Aura

Chrome version: 36.0.1985.103 Channel: beta
OS Version: Ubuntu 14.04
Flash Version:

This is on a 15W Intel Haswell device. Load was tested as follows.

$ htop
$ intel_gpu_top

Screenshots attached of idle GPU, and with tab spinning. It makes no
difference if the tab is selected or not.

Attachments:
t1.png 33.2 KB
t2.png 39.4 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 391646 by pdknsk: tab spinner ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

http://wait100sec.appspot.com/

[chro...@googlecode.com]

Comment #2 on issue 391646 by pdknsk: tab spinner ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Flash 3D: Hardware accelerated
Flash Stage3D: Unavailable. Hardware acceleration unavailable
Flash Stage3D Baseline profile: Unavailable. Hardware acceleration
unavailable
Compositing: Hardware accelerated and threaded.
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
WebGL: Hardware accelerated

Driver Bug Workarounds
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_ext_occlusion_query
disable_post_sub_buffers_for_onscreen_surfaces

Problems Detected
Accelerated 2d canvas is unstable in Linux at the moment
Disabled Features: accelerated_2d_canvas
Stage3D is not supported on Linux: 129848
Disabled Features: flash_stage3d
Accelerated video decode is unavailable on Mac and Linux: 137247, 133828
Disabled Features: accelerated_video_decode
GPU rasterization is whitelisted on N4, N5, N7 and Moto X: 362779
Disabled Features: gpu_rasterization
EXT_occlusion_query appears to be buggy with Intel GPUs on Linux
Applied Workarounds: disable_ext_occlusion_query
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Disable partial swaps on linux drivers: 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces

Driver Information
Initialization time 43
Sandboxed true
GPU0 VENDOR = 0x8086, DEVICE= 0x0a16
Optimus false
AMD switchable false
Driver vendor Mesa
Driver version 10.1.3
Driver date
Pixel shader version 1.30
Vertex shader version 1.30
Machine model name
Machine model version
GL_VENDOR Intel Open Source Technology Center
GL_RENDERER Mesa DRI Intel(R) Haswell Mobile x86/MMX/SSE2
GL_VERSION 3.0 Mesa 10.1.3

[chro...@googlecode.com]

Updates:
Labels: Cr-Internals-GPU Performance-Power Cr-Internals-Aura

Comment #7 on issue 391646 by bau...@chromium.org: tab spinner ridiculously

taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #10 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
http://code.google.com/p/chromium/issues/detail?id=391646

I didn't know which events to recorded so I just selected all.

Attachments:
trace.json.gz 2.5 MB

[chro...@googlecode.com]

Updates:
Cc: lu...@chromium.org

Comment #11 on issue 391646 by lu...@chromium.org: tab spinner ridiculously

taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #12 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Any clue from the trace?

[chro...@googlecode.com]

Comment #15 on issue 391646 by mar...@chromium.org: tab spinner

ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Other than the compositor, nothing springs to mind. Could you try disabling
the compositor and see if that's better?

[chro...@googlecode.com]

Comment #16 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Do you mean Unity? I tried xtrace. This is repeated while the tab spins.

13.008 003:<:056b: 20: DRI2-Request(154,7): GetBuffersWithFormat
drawable=0x03200001 attachments={attachment=BackLeft(0x00000001)
format=0x00000020};
13.008 003:>:056b:52: Reply to GetBuffersWithFormat: width=1200 height=1896
buffers={attachment=BackLeft(0x00000001) name=0x00000053 pitch=5120 cpp=4
flags=0x00000000};
13.008 003:<:056c: 8: DRI2-Request(154,9): GetMSC drawable=0x03200001
13.008 003:>:056c:32: Reply to GetMSC: ust_hi=3 ust_lo=4252180907 msc_hi=0
msc_lo=847752 sbc_hi=0 sbc_lo=146
13.009 003:<:056d: 4: XFree86-VidModeExtension-Request(152,0): QueryVersion
13.009 003:>:056d:32: Reply to QueryVersion: major-version=2 minor-version=2
13.009 003:<:056e: 8: XFree86-VidModeExtension-Request(152,14):
SetClientVersion major=2 minor=2
13.009 003:<:056f: 4: XFree86-VidModeExtension-Request(152,0): QueryVersion
13.009 003:>:056f:32: Reply to QueryVersion: major-version=2 minor-version=2
13.009 003:<:0570: 8: XFree86-VidModeExtension-Request(152,14):
SetClientVersion major=2 minor=2
13.009 003:<:0571: 8: XFree86-VidModeExtension-Request(152,1): GetModeLine
screen=0
13.009 003:>:0571:52: Reply to GetModeLine: dotclock=154000 hdisplay=1920
hsyncstart=1968 hsyncend=2000 htotal=2080 hskew=0 vdisplay=1200
vsyncstart=1203 vsyncend=1209 vtotal=1235 flags=+hsync,-vsync reserved1=0
reserved2=0 reserved3=0 privsize=0
13.009 003:<:0572: 32: DRI2-Request(154,8): SwapBuffers drawable=0x03200001
target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0
remainder_lo=0
13.009 003:<:0573: 4: Request(43): GetInputFocus
13.009 003:>:0573: Event DRI2-BufferSwapComplete(102) drawable=0x00000002
ust_hi=52428801 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=147
13.009 003:>:0573: Event DRI2-InvalidateBuffers(103) drawable=0x03200001
13.009 003:>:0572:32: Reply to SwapBuffers: swap_hi=0 swap_lo=147
13.009 003:>:0573:32: Reply to GetInputFocus: revert-to=PointerRoot(0x01)
focus=0x03200001
13.039 003:<:0574: 20: DRI2-Request(154,7): GetBuffersWithFormat
drawable=0x03200001 attachments={attachment=BackLeft(0x00000001)
format=0x00000020};

[chro...@googlecode.com]

Comment #17 on issue 391646 by mar...@chromium.org: tab spinner

ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Right, unity is the compositor in your case. I think it would be
interesting to try with another windowing system (xfce comes to mind as it
doesn't have compositing enabled by default) and see if the same thing
happens, and attach a trace.

[chro...@googlecode.com]

Comment #18 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Without Unity.



Attachments:
t6.png 19.3 KB
trace.json.gz 2.9 MB

[chro...@googlecode.com]

Comment #19 on issue 391646 by pi...@chromium.org: tab spinner ridiculously

taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

Oh, smacks head. If you enable the (disabled-by-default) gpu.debug
category, the tracing system will take a screenshot of each frame on
swapbuffers, and that's what's taking all this time.

A trace with only enabled-by-default categories (the ones on the left),
plus maybe gpu.service, gpu.device and cc.debug may help. Though I'm not
sure it'll tell us much more than what we have now.


Keep in mind that having the GPU 30% busy is not unexpected. Haswell
dynamically adjusts the GPU clock, so 30% as reported by intel_gpu_top is
relative to the current clock, not the max clock.
In /sys/kernel/debug/dri/0/ you can cat i915_cur_delayinfo and
i915_max_freq that will give you the current clock and the max clock.

So it looks like both Unity and Chrome each take about 30-35% of the GPU.
When you combine both you get to 66%. That's consistent because they're
probably both doing the same thing.

Partial swaps would most likely help... I wonder if we can reenable them
after r272290.

[chro...@googlecode.com]

Comment #20 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
http://code.google.com/p/chromium/issues/detail?id=391646

The trace is with Unity again.



Attachments:
trace.json.gz 969 KB

[chro...@googlecode.com]

Comment #21 on issue 391646 by dan...@chromium.org: tab spinner

ridiculously taxes the GPU
http://code.google.com/p/chromium/issues/detail?id=391646

The GPU process looks mostly idle in this trace. Though there's huge
trace_event_overhead blocks which I assume are unrelated.

Each swap buffers is blocking for the duration of a VSync, which I guess is
because we are blocking on it for our backpressure because we don't have a
scheduler vsync aligning things just yet in this trace. But that doesn't
seem problematic either.

In the watchdog section there appears to be about 25 binds and 45
drawelements calls per frame, which take 3ms. That does seem like a lot for
a tab spinner, but I guess that's because we're drawing the full window
instead of just the spinner. Still 3ms of 16 should be 20% of the GPU
cycles.

What were you seeing when you took this trace? Was the GPU
being "ridiculously taxed"?

[chro...@googlecode.com]

Comment #24 on issue 391646 by berendde...@gmail.com: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Have exactly the same problem here, for a long time, and even up to Chrome
38. If you have a tab that's waiting for http authentication for example,
or a notification, Chrome takes up 23% of cpu per tab, while doing nothing.

[chro...@googlecode.com]

Updates:
Cc: skyos...@chromium.org

Comment #25 on issue 391646 by mlamo...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #26 on issue 391646 by lukas.ri...@gmail.com: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I can confirm this (Chrome 42.0.2311.135) using Unity/Ubuntu 15.04 on an
Ivy Bridge GPU – my fan will spin up if there is even a single spinning tab.

[chro...@googlecode.com]

Comment #27 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I have some questions to everyone who is subscribed to this bug and notices
the same problem.

Linux?
Ubuntu?
Unity?
Intel?

Perhaps this is not necessarily, or only partially, a Chrome bug, but also
an Ubuntu or Intel bug.

[chro...@googlecode.com]

Comment #28 on issue 391646 by roland.p...@gmail.com: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Under Windows it seems to tax the CPU, even when in some background window.
So I would conclude the spinner itself does something too much.

[chro...@googlecode.com]

Comment #31 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I think the bug here is that the spinner causes the whole window to be
repainted (at 60 FPS no less) even though only 16x16 pixels are updated.

I enabled continuous repaint on this page, and get the same 60-70% GPU
utilisation.

I also did another test on this page, scrolling the page to a random
position in short intervals, using this code in console.

window.setInterval(function() {window.scroll(0, Math.random() *
(document.body.clientHeight - window.innerHeight))}, 100);

250ms: 10% GPU
100ms: 25% GPU
33ms: 45% GPU
16ms: 70% GPU

This shows that the problem is the update at high FPS for many seconds when
the spinner spins. Normal browsing behaviour, such as scrolling or page
loading, which usually only happens in bursts and not continuously for
seconds, causes low GPU utilisation.

[chro...@googlecode.com]

Comment #32 on issue 391646 by dan...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

That boils down to "We don't have partial swap support" and "The tab
spinner probably doesn't need to be 60fps". The first would fix this
generally, the 2nd would at least help the spinner.

[chro...@googlecode.com]

Comment #34 on issue 391646 by lukas.ri...@gmail.com: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

For the record, there is an equivalent issue for the download progress icon
on my machine: the GPU is active (i.e. in no sleep state) 100% of the time;
minimizing the Chromium window reduces that to about 35%. My laptop fan
actually spins up as long as a download is running in Chromium...

Strangely, intel_gpu_top only reports 3% render load though. Could it be
that the animation GPU access patterns don't actually cause high GPU load,
but prevent GPU sleep states?

[chro...@googlecode.com]

Updates:
Status: Untriaged
Labels: Hotlist-Polish

Comment #35 on issue 391646 by dan...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

It would probably be a great idea if the aura ui used cc's UIResources for
animating things, that way it uploads the frames once and just has to swap
IDs from then on. Instead of repainting every frame causing an upload every
frame for the whole animation.

[chro...@googlecode.com]

Updates:
Status: Available

Comment #36 on issue 391646 by vmi...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #42 on issue 391646 by tap...@chromium.org: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Like this: https://codereview.chromium.org/1381203002/#ps160001 :) ? (still
a WIP).

Basically, I made an energy usage test harness for Mac. Throbbers on mac
are just PNG frames and a waiting throbber uses about 2 watts of energy
above idle (idle is also about 2 watts).

Running the toolkit-views throbber uses about 11 watts above idle (ands
lots of CPU), which is no good. The throbbers are pretty different though
-- the views waiting throbber "grows" at the start, and the loading
throbber changes its arc length each frame. On Mac, it's just a looping arc
of the same length.

Just making the throbber layer-backed (still repainting to a Canvas each
frame) brings this down to about 4 watts above idle. That change is pretty
simple (see Patchset 8 e.g.
https://codereview.chromium.org/1381203002/diff/140001/chrome/browser/ui/views/tabs/tab.cc)

Patchset 9 rotates the waiting throbber with a transform and clips it at
the start to get the growing effect - I'm testing it now. But it has the
downside of losing some "crispness" since the rotation mis-aligns the pixel
AA that Skia does (I have an idea for this though). Running tests with that
now.

Accelerating the loading throbber is trickier, but I think it can be done
using some ideas from
https://blog.keanulee.com/2014/10/20/the-tale-of-three-spinners.html

[chro...@googlecode.com]

Updates:
Status: Started
Owner: tap...@chromium.org

Comment #43 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

so, update: animating with a layer-transform using the existing timer setup
in BrowserView doesn't have a significant benefit versus the
just-make-the-throbber-a-layer change. They both come in at about idle +
2.5W (+/- 0.2W) in my measurements.

So I think the bulk of the saved ~8.5W is coming from cutting out the
requirement to descend into calls to repaint the entire browser frame. Even
though it's a small damage rectangle, and --ui-show-paint-rects shows the
compositor doing a good job just updating that part, there's still a lot of
work being done culling out child views and things.

Offloading the transform animation-step to a "proper" animation timer may
have some additional gains, but requires a big overhaul (e.g. the same
timer updates an "immersive" browser's menubar .ico).

Since the benefit of the layered, non-transform approach is significant and
it's a simple change (up in https://codereview.chromium.org/1393193002) I
think it's worth doing.

Transforms will add complexity -- particularly for the pulsating arcs we
have now -- and might not give us the desired pixel-crispness, but might
still be worth exploring. Plus, adding a layer is probably a first step for
that anyway.

[chro...@googlecode.com]

Comment #44 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Attaching plots for https://codereview.chromium.org/1393193002

Tests were run with 33 passes, each time running for a ~10 second window (a
few seconds after startup), sampling every 50ms for the average wattage
since the last sample was taken.

the "timeline" is just one of the runs to get an idea of
consistency. "runs" is all 33 runs with error bars showing the standard
deviation of samples taken during that run (on a few of the runs my laptop
decided to do some background task, but it's otherwise pretty stable).

"master" here is r352743
"crrev/1393193002" is the result after applying http://crrev.com/1393193002

Test harness and scripts to generate the data and plots is at
https://codereview.chromium.org/1393233002/#ps80001

Attachments:
throbber-timeline.png 279 KB
throbber-runs.png 214 KB

[chro...@googlecode.com]

Comment #46 on issue 391646 by s...@chromium.org: tab spinner ridiculously

taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Have you tried short circuiting the painting paths for the throbber and
measuring the impact? I'm suggesting that when repainting because of the
throbber call directly into tab? Yes, this is a hack, but I'm curious what
the measurements look like.

[chro...@googlecode.com]

Comment #47 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Short Circuiting: I tried a couple of things
(https://codereview.chromium.org/1392423002) - just repainting without
correct transforms, or repainting only children on the path to the throbber
didn't impact power usage -- always stayed around 13.5 watts.

So, still on master, I tried commenting out the `PaintChildren()` call in
View::Paint(). Then it dropped to about 12.3 watts. Of course, nothing
actually got painted. But I think it suggests that it's the requirement to
`BeginMainFrame` on the much bigger window layer that's causing the hit.
Sure enough, making the window much smaller can bring the wattage down to
~5 watts. Making the window fill the screen will nudge it up to 15+ watts.

I think this is consistent with Dana's comments on crrev.com/1393193002 --
it's cheaper to animate content in a small layer than a small part of a
larger layer. But the size of that larger layer plays a significant role. I
also had to question whether this might be specific to platform-specific
ways of transferring pixels between processes, since the wattage analysis
was running on a MacBook Pro. The same library for reading from MSRs on
Linux is out of date and a bit rubbish (and I don't have a clean laptop set
up for other platforms), so I made do reading some CPU usage% from top on
Linux:

It looks like the CPU% impact on Linux is pretty significant too. Before
this change I was seeing 53.3% CPU for the browser process and 7.2% CPU for
the GPU process. With crrev.com/1393193002, this goes down to 6.6% / 4.7%.

Then, to answer Dana's question in #45. I verified the paint using the
transform approach was only happening once. (I cleaned up the code a bit,
based it off crrev/1393193002 and put it in http://crrev.com/1400783002/).
There *is* an impact on CPU utilization: browser process goes from 6.6% ->
5.3% for a single throbber (gpu process unchanged).

I'll take a closer look at the power usage plots for the transform change
too - it might be the incremental improvement wasn't showing up. Maybe it's
still worth doing just the (much simpler) "waiting" throbber if we assume
that's the one that might stick around (versus the "loading" throbber which
will either finish loading or timeout in a shorter timeframe).

[chro...@googlecode.com]

Comment #48 on issue 391646 by pkas...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

FWIW, I don't think it's safe to guess that one of the two throbbers will
hang around much longer than the other -- I've seen what seem like an equal
number of cases of long durations of each.

[chro...@googlecode.com]

Comment #49 on issue 391646 by bugd...@chromium.org: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646#c49

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/23f218dbb7d9f4fd2401e71bfa5f23af32d13800

commit 23f218dbb7d9f4fd2401e71bfa5f23af32d13800
Author: tapted <tap...@chromium.org>
Date: Thu Oct 22 08:45:07 2015

Paint tab-loading throbbers into a ui::Layer.

In views browsers, updating the tab loading throbber currently requires
a repaint that starts at the BrowserView and trickles the damage
rectangle down until it reaches the favicon area. This uses a lot of CPU
and energy: about 11 watts above idle on a MacBook Pro (and significant
CPU on Linux) for a single "waiting" spinner.

Giving the throbber a layer allows the repaint to be isolated, with
compositing done on the GPU. This brings total energy usage down to
about 2.5 watts above idle.

Plots at http://crbug.com/391646#c44

BUG=391646
TEST=Spinners should look and behave the same, but use less energy/CPU.

Review URL: https://codereview.chromium.org/1393193002

Cr-Commit-Position: refs/heads/master@{#355514}

[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab.cc
[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab.h
[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab_controller.h
[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab_strip.cc
[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab_strip.h
[modify]
http://crrev.com/23f218dbb7d9f4fd2401e71bfa5f23af32d13800/chrome/browser/ui/views/tabs/tab_unittest.cc

[chro...@googlecode.com]

Comment #54 on issue 391646 by briander...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Those are awesome results!

@tapted: How hard would it be to measure the power usage with a 60fps
spinner + your optimizations? We've enabled cc::Surfaces and added a
cc::DisplayScheduler recently, which should be better at coordinating
simultaneous UI and Renderer updates than before.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:546846

Comment #55 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #56 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

The CL above doesn't yet attempt to use compositor animation timers -- it's
all rolled into a timer on BrowserView, and the layer is still repainted
each frame rather than animating a transform.

There are some ideas in https://codereview.chromium.org/1400783002/ that go
the next step, and animate a transform rather than redraw. But only for the
waiting throbber. Doing the loading throbber would be harder. See also
#c43, #c47.

Even after that, I think there's a tricky refactor to move away from using
the base::RepeatingTimer in BrowserView to advance the animation, since it
can also be used to update the shell icon displayed in the titlebar on
Windows for some window types.

[chro...@googlecode.com]

Comment #58 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Yes - there's a tricky lifetime problem captured in Issue 546846 that I
need to sort out first. But it will need to wait until I'm back from
vacation :)

[chro...@googlecode.com]

Comment #59 on issue 391646 by Kurtextrem: tab spinner ridiculously taxes
the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

...which is not public :(

[chro...@googlecode.com]

Comment #60 on issue 391646 by dan...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I can't see it either, heh.

[chro...@googlecode.com]

Comment #61 on issue 391646 by osh...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Chrome becomes very janky during session restore, and I wonder if it is
because of a lot of spinners.

I managed to get the trace. danakj@, can you take a look and let me know
what you think?

Attachments:
trace_startup_jank.json.gz 9.4 MB

[chro...@googlecode.com]

Comment #65 on issue 391646 by bugd...@chromium.org: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646#c65

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/e540e65b1024433c088933f558095a5e849dea25

commit e540e65b1024433c088933f558095a5e849dea25
Author: tapted <tap...@chromium.org>
Date: Tue Dec 01 22:41:01 2015

Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer
is invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.

Review URL: https://codereview.chromium.org/1474993003

Cr-Commit-Position: refs/heads/master@{#362535}

[modify]
http://crrev.com/e540e65b1024433c088933f558095a5e849dea25/ui/compositor/layer_owner.h
[modify]
http://crrev.com/e540e65b1024433c088933f558095a5e849dea25/ui/views/view.cc
[modify]
http://crrev.com/e540e65b1024433c088933f558095a5e849dea25/ui/views/view.h
[modify]
http://crrev.com/e540e65b1024433c088933f558095a5e849dea25/ui/views/view_unittest_aura.cc

[chro...@googlecode.com]

Comment #66 on issue 391646 by bugd...@chromium.org: tab spinner
ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646#c66

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/859410a5e85488c0b79de51814351f30cf2814a5

commit 859410a5e85488c0b79de51814351f30cf2814a5
Author: tapted <tap...@chromium.org>
Date: Thu Dec 03 03:00:38 2015

Paint tab-loading throbbers into a ui::Layer (reland).

In views browsers, updating the tab loading throbber currently requires
a repaint that starts at the BrowserView and trickles the damage
rectangle down until it reaches the favicon area. This uses a lot of CPU
and energy: about 11 watts above idle on a MacBook Pro (and significant
CPU on Linux) for a single "waiting" spinner.

Giving the throbber a layer allows the repaint to be isolated, with
compositing done on the GPU. This brings total energy usage down to
about 2.5 watts above idle.

Plots at http://crbug.com/391646#c44

Previously reviewed in https://codereview.chromium.org/1393193002/.
Landed but reverted since it tickled a pre-existing lifetime issue,
now fixed.

BUG=391646
TEST=Spinners should look and behave the same, but use less energy/CPU.

Review URL: https://codereview.chromium.org/1477713002

Cr-Commit-Position: refs/heads/master@{#362878}

[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab.cc
[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab.h
[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab_controller.h
[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab_strip.cc
[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab_strip.h
[modify]
http://crrev.com/859410a5e85488c0b79de51814351f30cf2814a5/chrome/browser/ui/views/tabs/tab_unittest.cc

[chro...@googlecode.com]

Comment #69 on issue 391646 by pdknsk: tab spinner ridiculously taxes the
GPU
https://code.google.com/p/chromium/issues/detail?id=391646

Yes, but it's worse without the use_virtualized_gl_contexts workaround.

[chro...@googlecode.com]

Comment #70 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I'll revisit my analysis for Linux in #c47 on an official release. Per the
analysis there, there was a much bigger impact to the browser process
(53.3% to 7.2% versus 6.6% to 4.7% for the GPU process) - maybe you see a
change there?. The previous analysis was done in an isolated test case:
generally there's a lot of "stuff" going on in Chrome that can be hard to
pin down. Note there's also Issue 534970 specifically for the browser
process as opposed to the Chrome's GPU process.

On Linux and Mac - both processes need to be considered since some of the
interplay with the OS's Window Manager, and ownership of some GPU
resources, can only be done by the browser process.

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---
Cc: tap...@chromium.org

Comment #71 on issue 391646 by tap...@chromium.org: tab spinner

ridiculously taxes the GPU
https://code.google.com/p/chromium/issues/detail?id=391646

I've done some analysis on Linux. tl;dr: there's a 19% improvement in *CPU*
usage after r362878 for Chrome showing a single throbber. r362878 is also
the first step in exploring composited throbber animations which could take
this a lot further.

"19%" = 22.23 +/-0.18 CPU seconds over 5 minutes going to 18.07 +/-0.09 CPU
seconds.


Longer story:

The tooling is still not ideal -- the power draw analysis I was able to do
on a Macbook gives a much nicer number to optimize against, and encompasses
all chrome processes and the GPU chip.

I think for Linux and GPUs there's a minefield of problems. Kernel/x11
drivers, hardware support, various window managers and compositors really
make a mess of things. I wasn't able to reproduce the pathological case in
Issue 534970 any more - a single throbber (layered or unlayered) on my
setup didn't spike above ~10% CPU. Tried a bunch of window managers with an
NVIDIA card (GF108GL [Quadro 600]) all using DRI but not always a
composited window manager.

For *GPU* utilization, it also hovers around 10% according to nvidia-smi
(NVIDIA's closest thing to intel_gpu_top). Statistically, this is unchanged
with/without layering for the throbber. nvidia-smi doesn't give numbers any
more precise than whole percentages.

To arrive at "19%" I did:
Pin the CPU at 1200MHz to rule out frequency scaling.
In the background: `nc -kl 8080` to accept connections.
For 5 minutes, run `chrome http://localhost:8080
--user-data-dir=<initially empty dir>`.
1 warmup run, then repeat 20 times for each of {layered, unlayered}
throbber
Collect total CPU utilization for all UI process tasks
Average over the 20 runs. Error range is the 90% confidence interval for
the true mean.

Script, data files and a plot attached.

Since there's other performance stuff going on between releases, I couldn't
really pinpoint whether r362878 was specifically involved without
recompiling, so I made release builds at ToT r367046 (~49.0.2606.0).
However, spot checks against CPU utilization show that it's comparable.
Note the "CPU seconds measured" is just the UI process: On my setup,
Chrome's GPU process showed a similar reduction in utilization (but as said
above, the GPU *chip* didn't show a significant change when measured with
nvidia-smi). To isolate layered/unlayered, I just had
TabController:CanPaintThrobberToLayer() return true or false.

Moving to available since I'm not active on this right now, but might be
inspired to work on it closer after more analysis on Mac with the full
power draw.

There still might be a pathological case that takes {CPU or GPU}
utilization up much higher (Issue 550961 perhaps?), but I haven't been able
to reproduce it.

10% utilization of the GPU chip (a Quadro 600 in this case) might also be
something worth improving, but 10% (on my window manager) is pretty normal
for something updating a character-sized portion of the screen ~30 times a
second in any program (i.e. not just Chrome). I haven't figured out how to
break the GPU chip utilization down into things being "done" by Chrome, the
window manager/compositor, or by GPU/DRI drivers.

Attachments:
throbber-linux-unity.png 35.0 KB
throbber_perf.sh 742 bytes
layer_false.txt 966 bytes
layer_true.txt 966 bytes