1963593 - earth.google.com - Uses 100% of CPU when using NVDIA GPU

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Arch Linux
Firefox version:

Preconditions:
NVIDIA GPU used

Steps to reproduce:

1. Navigate to: https://earth.google.com/
2. Browse and observe

Expected Behavior:
No performance issue

Actual Behavior:
100% CPU usage

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/150531

Comment 1

[Raul Bucata]

I do not own an NVIDIA Graphic card, but I have moved the issue based on the user comments and the fact that is a top site.

Comment 2

[Alexandra]

https://profiler.firefox.com/public/99hmh0f2mmzrm9ggsas46ksf0zdv7m3109cxdar/calltree/?globalTrackOrder=0&thread=1&v=10

does a profile help?

Comment 3

[Radek Průša]

Attachment: about:support

Comment 4

[Radek Průša]

I also have this issue. My computer basically freezes if I open Google Earth using Firefox. Contents of about:support attached in above comment.

Comment 5

[Radek Průša]

Profiler capture of the issue in a clean profile with default settings and no extensions.

https://share.firefox.dev/45LRoVL

Comment 6

[Ashley Hale [:ahale]]

I really have no idea how to go about debugging this, unfortunately.

Comment 7

[Brad Werth [:bradwerth]]

(In reply to [:nickname]Atmospheric Ignition from comment #5)

Profiler capture of the issue in a clean profile with default settings and no extensions.

https://share.firefox.dev/45LRoVL

Erik, this profile shows almost all of the time is in the driver itself. Can you give us some insights into what we could be doing to improve the usage of the driver?

Comment 8

[Erik Kurzinger]

(In reply to Brad Werth [:bradwerth] from comment #7)

(In reply to [:nickname]Atmospheric Ignition from comment #5)

Profiler capture of the issue in a clean profile with default settings and no extensions.

https://share.firefox.dev/45LRoVL

Erik, this profile shows almost all of the time is in the driver itself. Can you give us some insights into what we could be doing to improve the usage of the driver?

I left NVIDIA last year so I don't have access to the driver code any more. You might be able to get someone's attention by posting on their forum https://forums.developer.nvidia.com/c/gpu-graphics/linux/148

Comment 9

[aleino]

From the profile in comment 5 it looks like most samples landed in glCopyTexSubImage2D.
I'm not sure what from the call-stack can be trusted beyond that point, but at least it seems glCopyTexSubImage2D winds up making lots of calls to __clock_gettime_2, probably busy-waiting.

In other words, glCopyTexSubImage2D is probably forced to wait on the GPU for some reason -- doesn't necessarily imply glCopyTexSubImage2D is doing anything inappropriate, itself.

Does this map back to a single/a few copyTexImage* calls in the WebGL code?

Did you raise this with the Google Earth team yet?
I think a JavaScript profile from Google Earth may be interesting. Do any particular copyTexImage* calls stand out there?

Comment 10

[Ashley Hale [:ahale]]

Thanks for the analysis.

It's hard to guess why it would be taking a long time in glCopyTexSubImage2D, I wouldn't expect Google Earth to be copying a lot of pixels from an FBO to a texture, I can only speculate that there must be some very large rendering going on and then copying to texture, as I can't imagine it taking a long time otherwise unless the video card is running on an extremely slow PCI-E bus (eGPU?) and copying across GPUs perhaps, but that is purely speculation.

We probably need to understand the WebGL access pattern in Google Earth a bit better.

Comment 11

[lostdharmai]

Using the alternative "Mobile user interface mode" in Google Earth fixes the performance issues, as demonstrated here:
https://www.reddit.com/r/firefox/comments/1qd4z3e/if_google_earth_is_unusable_for_you_heres_a_quick/

Could this be set as a workaround until the issue is fixed?

Comment 12

[Brad Werth [:bradwerth]]

Very good find, thank you. That will at least let us compare what WebGL calls are being made vs the two modes.

Comment 13

[Radek Průša]

I've recently started noticing this issue also happening in Chromium-based browsers which didn't use to have this issue about a month or two ago.