1622612 - Spikes in Webrender GPU usage with 60fps video on Intel gen7 Linux

Status: RESOLVED FIXED

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

Description

[Thomas Daede [:TD-Linux]]

Attachment: Screenshot from 2020-03-15 02-04-32.png

On this relatively weak internal gpu, there are occasional huge spikes in B_YuvImage. The time of the spikes is directly proportional to the size of the window - if the window is scaled down sufficiently so that the spikes are under 16ms, the video manages a consistent 60fps.

Comment 1

[Glenn Watson [:gw]]

Are the spikes noticeable via other means (i.e. visual frame drops, or the FPS counter)? Does this seem to be a recent regression, or has it always been like this?

I think that in some cases the timers can report inaccurate values, although I doubt that's what is happening here. I suspect another possible cause of spikes is when the driver does GPU work for another process (or the system compositor), it can show up in our timers, as we have no way to detect this with our current implementation.

I'll take a look and see if I can repro locally. There is support in GL on some drivers for detecting these disjoint timer events, it's probably worth me supporting that and seeing if that lines up with the spikes at all.

Comment 2

[Thomas Daede [:TD-Linux]]

Yes, they are clearly visible . I don't watch 60fps videos that much so this has probably been around for a while.

I thought it might be the system compositor, so I ran fullscreen to bypass it (at least, I think it bypassed it...). It's still possible that something else is eating GPU time, though. I thought it weird that it was specifcially always hitting B_YuvImage which normally takes a very short time, but there also could be some hidden synchronization point in there in the driver.

Comment 3

[Thomas Daede [:TD-Linux]]

(I mostly noticed it because the game being streamed strobes its shadows at 30hz, making the dropped frames very visible)

Comment 4

[Glenn Watson [:gw]]

I did some testing with this on an HD4600 GPU with current nightly on Kubuntu 19.10.

I was testing with the source video quality set to be 1080p@60.

I tested with the window size at 3 resolutions:

• 1920 x 1080 - Holds stable 60fps, GPU timers are stable (no spikes).
• 1920 x 2160 - Holds stable 60fps, GPU timers are stable (no spikes).
• 3840 x 2160 - FPS is stable, but not 60fps (~55 fps). GPU times are stable (no spikes), reporting ~4.6ms / frame.

So, I haven't seen any spikes in the GPU timers on this page / configuration, which is interesting. The GPU time when running at 3840 x 2160 seems close to optimal for that GPU, so that's good too.

I'm not sure exactly why it's not holding 60fps at 4k - it might be memory bandwidth of decoding that video + drawing at 4k on that GPU, or perhaps there is a bottleneck elsewhere in the media stack causing issues in this case.

Some questions:

• What source resolution and display resolution are you using?
• What is the GPU?
• What distro / mesa / compositor / wm are you running?
• Was this testing on nightly? (this has some significant video optimizations that aren't in the current beta/release).

Comment 5

[Thomas Daede [:TD-Linux]]

• 2880 x 1620
• HD4600 (intel i7-4900MQ)
• Fedora 31, gnome-shell, mesa 19.2.8
• Nightly, but caveat below:

I realized my nightly hadn't updated and was stuck on 2020-03-09. I updated (as well as closing other apps etc) and ended up with a super smooth 60fps. So I guess some recent change may have fixed it. One oddity, though, is that the profiler no longer shows very much detail. If I don't move the mouse and no elements get redrawn, I get a result that looks like the attached screenshot.

Comment 6

[Thomas Daede [:TD-Linux]]

Attachment: Screenshot from 2020-03-16 18-47-04.png

Comment 7

[Glenn Watson [:gw]]

The patch that enabled all the recent video optimization work [1] landed on March 10th, which would fit in well with the timeline between seeing this issue and seeing stable 60fps in the currently nightly.

The reason there is much less detail in the profiler is (mostly) because WR is now doing a lot less work in this case. Videos can be promoted to "compositor surfaces" now, which means that they are decoded directly into the framebuffer, and drawn at the same time / pass as the picture cache tiles.

So the composite time metric you see in the profiler is showing time to composite picture cache tiles (that don't need any updating) and the YUV planes for the video directly into the framebuffer. Unfortunately, due to some limitations in the current GPU profiler, it's not super simple to make the graph show up separate entries for where the YUV planes are being composited into the framebuffer (we should support this in future though).

Given the above, should we close this as fixed?

[1] https://phabricator.services.mozilla.com/D64007

Comment 8

[Thomas Daede [:TD-Linux]]

Indeed, that makes a lot of sense, thanks.

I also tried moving my mouse around to cause the video overlay to appear and skip the fast path, but I couldn't reproduce the spikes. I don't know if that's due to other things being improvements, or less load on the system, or what.