1452489 - Mac: WebRender causes huge power GPU power consumption during some scrolls

Status: NEW

(Core :: Graphics: WebRender, defect, P2)

Description

[Mark]

Attachment: arstechnica scrolling GPU power.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180408100251

Steps to reproduce:

MacBookPro 11,1 at 1280x800 default resolution
Nightly 2018-04-08
gfx.compositor.glcontext.opaque TRUE

Default resolution and opaque window so GPU power consumption of MacOS compositor is low, ~3.0 W for most tasks. If I turn WebRender ON, mostly the GPU load stays similarly low but can jump enormously high on some scrolling

e.g.

GPU power consumption                                            WebRender
                                                             OFF            ON                        
gsmarena.com                                                
(scrolling up and down near the very TOP of the page)       3.0 W        16.0 W
(scrolling up and down near the very BOTTOM of the page)    3.0 W         3.0 W

arstechnica.com                                            
(scrolling up and down near the very TOP of the page)       3.0 W        17.3 W                                                        
(scrolling up and down near the very BOTTOM of the page)    3.0 W         3.0 W

For most sites the GPU load stays low regardless of where I scroll on the page. But for these two examples, scrolling up and down near the very top of the page causes enormous GPU power consumption, around 16 W (I think it would be more but my Intel package is maxed out, see below). But scrolling the rest of the page, once the top of the page is out of view, causes only “normal” GPU power consumption of around 3.0 W.

So I think that normally WebRender is not working my GPU very hard at all, but there are odd edge cases where it goes bananas. 

Hopefully easy for you to spot because, given the fixed MacOS compositing load of ~3.0 W,  WebRender’s power consumption jumps by at least one, and maybe two orders of magnitude.

There is already a WebRender bug 1421784 against arstechnica.com about it only running at 30 fps, perhaps this is the cause?

I did a shonky video on my phone of arstechnica.com. In the menu bar you can see CPU load graph, CPU watts and GPU watts from iStat Menus; at the left of the screen you can see Intel Power Gadget. Scrolling at the top of the screen puts the GPU up to around 17 W and redlines the Intel package at 28 W (from Power Gadget). Note also the GPU clock (middle graph) goes from 0.32 GHz at the top of the page to 0.18 GHz at the bottom. So at the top of the page the GPU is working its &*^% off for no very good reason?

WebRender would be my daily driver if not for this glitch. Enjoy!

Comment 1

[Jeff Muizelaar [:jrmuizel]]

If you turn on gfx.webrender.debug.gpu-time-queries and gfx.webrender.debug.profiler you should be able to see how many ms is being spent on the GPU during those times. It would be valuable if you could report the numbers you see here.

Comment 2

[Mark]

On arstechnica.com

If I jiggle scroll at the top of the page for maybe 15 seconds the numbers under GPU go Min: 4 ms Mean: 12 ms Max: 13 ms

If I ditto at the bottom of the page Min: 3.5 ms Mean: 3.8 ms Max: 4.3 ms

Looking at the three CPU bar graphs everything is working a lot harder when I jiggle at the top of the page:- CPU (backend); CPU (compositor); DisplayList IPC all show enormous spikes compared to jiggling the bottom of the page.

Screengrab attached of some jiggle scrolls at top vs bottom, I hope it makes sense

Comment 3

[Mark]

Attachment: CPU & GPU arstechnica.png

Comment 4

[Mark]

Plus, I think the 12 ms of GPU time at the top of the page is at twice the GPU clockspeed of the 4 ms at the bottom of the page. So IIUC Firefox is asking the GPU to do ~6x the work at the top as at the bottom?

gsmarena.com shows roughly the same though the top of the page is not such hard work, more like 10 ms (gsmarena.com) vs 12 ms (arstechnica.com)

Comment 5

[Mark]

I think it's blur. When gfx.webrender.debug.profiler is TRUE, looking at your horizontal bar graph with the fancy colours I see lots of Blur and B_MixBlend when power consumption is high. 

arstechnica & gsmarena seem to use blur or B_MixBlend near the top of their pages, and that seems to hit the GPU very hard??

Two codepen blur examples which hit my GPU very hard when the blur is happening:-

https://codepen.io/onge/pen/KwdZpE
(if you monkey with the animation timing you can get the blur animation going continuously. My GPU power rises to ~15 W at 1280x800. If you monkey with the AMOUNT of blur by changing @keyframes pixel value the GPU power changes. Smaller blur pixel values mean lower GPU power)

https://codepen.io/YuriK/pen/wyxEm
(mouseover to get the blur. Do this repeatedly, my GPU power rises to ~15 W at 1280x800)

In both cases the TIME spent on the GPU is not huge, around 5 ms.


All with gfx.compositor.glcontext.opaque TRUE and 1280x800 full screen window, WebRender ON

Comment 6

[Mark]

Blur and mix-blend

I think gsmarena uses blur near the top of the page -> high GPU load on codepen blur examples, see comment 5 

I think arstechnica uses mix-blend near the top of the page -> high GPU load on codepen mix-blend examples, see 

https://codepen.io/mrnathan8/pen/MwqEOB

hover mouse over the examples & GPU redlines, 20 W!!

I have looked through the CSS stylesheets and it seems to tie up but I can't really read CSS.

MacBookPro 11,1
default 1280x800
Nightly 2018-04-08
gfx.compositor.glcontext.opaque TRUE
gfx.webrender.all TRUE

Comment 7

[Mark]

Another long post, sorry for so many. It’s driving me nuts.

I am stumped. The codepen mix-blend example might be a red herring. Chrome & Firefox both hit the GPU very very **** that example, whether using WebRender or not, or Core Animation or not.  

GPU power                        codepen     
                                mix-blend  

Nightly + WebRender               20 W   

Nightly - WebRender               18 W  

Chrome - Core Animation           18 W   

Chrome + Core Animation           21 W  

There seem to be some circumstances which redline the GPU even at 1280x800, for either browser. Another example is the blur animation on https://12speed.campagnolo.com/UK/en. Both browsers redline the GPU on that (Firefox without WebRender won't animate it at all!).

On my “real page” power problems only Firefox + WebRender has high GPU load when scrolling arstechnica & gsmarena top of page. And finally my Guardian slideshow bug 1419079 attachment 1 [details] [diff] [review] zoomed into to full screen has high GPU load on Firefox regardless of WebRender status. But Chrome handles all these real world cases with very lower power consumption.

GPU power                 arstechnica           gsmarena         bug 1419079
                      scrolling top page         ditto          slideshow big

Nightly + WebRender         19 W                  16 W              21 W

Nightly - WebRender          3 W                   3 W              20 W

Chrome - Core Animation      4 W                   4 W               4 W

Chrome + Core Animation      2 W                   2 W               4 W

I still think there is a GPU power funny in WebRender on arstechnica & gsmarena. And I still think blur and mix-blend are involved. But there are also funny high GPU power situations, on both browsers, which might be caused by blur (?) plus the MacOS compositor not the browser? I don't know why.



https://codepen.io/mrnathan8/pen/MwqEOB, expand lower frame so can see the whole of animation 2 & hover over it.
arstechnica.com, jiggle scrolling top of page. 
gsmarena.com, likewise
bug 1419079 attachment 1 [details] [diff] [review], zoomed in until Mugabe slideshow fills most of screen, peak power taken while animation is taking place

gfx.compositor.glcontext.opaque TRUE for Firefox
Core Animation disabled using —disable-mac-overlays for Chrome
WebRender on/off using gfx.webrender.all
Nightly 2018-04-08
MacBookPro 11,1 @ 1280x800, full screen browser window.

Comment 8

[Mark]

Could be a duplicate of bug 1436193?

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Glen, can you take a look at this when you get a chance?

Comment 10

[Glenn Watson [:gw]]

Yup, please feel free to assign this to me.

I am currently working on the infrastructure to cache blurs (and other off-screen targets) where applicable. Some of the initial work is https://github.com/servo/webrender/pull/2651.

I suspect once these changes land that will probably fix the power consumption issues here, however I'll try to repro this locally next week and confirm if caching of blurs is the problem here, or if something else is causing the issue in this case.

Thanks for the detailed bug report!

Comment 11

[Mark]

If it's easy, could you make a MacOS version of the Try in https://github.com/servo/webrender/pull/2651

Maybe I can have a play over the weekend and give some feedback ... perhaps another essay ;)

Comment 12

[Kartikaya Gupta (email:[e-mail])]

I added a MacOS build to that try push, should be done in ~1 hour.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3928cd6a91763adc7672f5a53c8ee003629bc536&group_state=expanded&selectedJob=173496243

Comment 13

[Mark]

i'm not sure it's made much difference for me. Taking Jeff's clouds:- https://jrmuizel.github.io/webrender/slow/clouds.html

I can see the caching working, there is less pink blur on the profiler histogram when I scroll. But I still only get ~20 fps @1280x800 when I scroll the clouds. Sometimes it gets its act together and I temporarily get 50 fps, but it's rare. GPU draws 12 W during scrolling which is huge.

If I pinch zoom Jeff's cloud to maybe 300% WebRender chokes and dies, down to about 1 fps.

Contrast WebRender OFF case where I get ~60 fps whether normal sized or pinch zoomed, and 3 W GPU power.


Same story for gsmarena.com. In principle I can see less pink blur on the profiler, in practice my GPU still draws ~16 W when scrolling which is very much the same as before.

So it hasn't fixed my gsmarena.com red hot GPU problem.

(unless I am using it wrong)

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Gecko, is usually pushing new paints during scroll, so we may be able to take advantage of the across scroll caching yet. See bug 1452390 for that.

Comment 15

[Mark]

Actually the Try version does give reduction in time spent on the GPU for gsmarena.com (which uses blur near the top of the page)

Mean GPU time from WebRender profiler; GPU clockspeed from Intel Power Gadget; 1280x800 full screen window; MacBookPro 11,1 (Intel Iris 5100 iGPU)

Top of page speed scrolling:- 
    stock nightly:         9.2 ms @ 0.32 GHz
    Try with bur caching:  8.4 ms @ 0.32 GHz
lower part of page speed scrolling:-
    both versions:         4.1 ms @ 0.19 GHz

So GPU load due to Firefox is down maybe 10% with the caching version. Progress!

The GPU is still working hard and very hot though. My guess is that when the GPU kicks into high clockspeed (0.32 GHz for me) its power consumption increases dramatically, that's when I see the 10-20 W GPU power consumption.

Comment 16

[Glenn Watson [:gw]]

Yea, I would expect only very modest improvements from this initial patch (since it only applies to scrolling the same display list so far, and Gecko will typically be providing new display lists).

Over the next few weeks there will be a significant number of patches landing that enable caching on various different element types in various different situations. I expect these should help a lot. I will try and reproduce on this specific site this week though, to see if it makes sense / is possible to prioritise focusing on the power issues in this specific case.

Comment 17

[Glenn Watson [:gw]]

I tested this again today. There are still significant issues on arstechnica.com, however I can no longer reproduce the issue on gsmarena.com (not sure if that's due to the page content changing or some WR optimizations).

Comment 18

[Glenn Watson [:gw]]

OK, I can see that on arstechnica.com there are a heap of images that have a multiply mix-blend-mode enabled. Right now, we don't cache them between frames, which means:

* Each image gets drawn to an off-screen target.
* The framebuffer does a readback into a temporary surface.
* The expensive mix-blend-mode shader is run to blend them to another surface.
* The final image is composited into the scene as a brush image.
* To make matters worse, all mix-blend-mode effects are currently considered to be translucent, so skip drawing into the opaque pass, which adds even more overdraw.

We can definitely draw these once into the texture cache and avoid a lot of this work each frame in this case.

The slightly tricky bit is working out when the cache is valid (for example, a mix-blend-mode that operates on top of a scroll layer may need to be re-rendered during scrolling). The common case is easy, but we need to make sure we detect these edge cases for correctness.

Comment 19

[Mark]

Sounds interesting

FWIW I still see fairly high power consumption scrolling near the top of gsmarena.com (12 W @ 1280x800), but it's not nearly as big as arstechnica.com (20 W @ 1280x800 which maxes out my iGPU). On the profiler I don't see any mix-blend on gsmarena.com but a lot of B_solid.

gsmarena.com might have got better (from 16 W down to 12 W) because of paint skipping, bug 1452390, or ... something else.

cheers