Closed Bug 1615061 Opened 4 years ago Closed 4 years ago

WebGL/WASM (SDL2, emscripten) slow on initial load but fast on reload

Categories

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

75 Branch
x86_64
macOS
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: code, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

  1. Open http://www.sy2002.de/tmp_test/qnice.html
    (WebGL/WASM canvas, based on SDL2, compiled with emscripten)
  2. Observe a low frame rate (FPS) on the top right corner: on my Mac: 3 FPS
  3. Press "Reload" (on my Mac this is Apple+R)
  4. Observe a high(er) frame: on my Mac: 10 FPS

Actual results:

It is perfectly reproducable that the first load of such a WebGL, Webassembly based app leads to super slow performance and after a reload it is 3x (or more) better.

The browser console (opened with the keys Apple+Shift+J) shows, that on the first run, Firefox seems to utilize the slow Intel GPU of my laptop and then on reload it seems to utilize the fast ATI Radeon Pro.

Expected results:

Just like Chrome, which utilizes the fast GPU also on first load, Firefox should do that, too.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Flags: needinfo?(jgilbert)
OS: Unspecified → macOS
Priority: -- → P3
Hardware: Unspecified → x86_64

I'm pretty sure this is bug 1597547, but this helps compel us to fix it! Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jgilbert)
Resolution: --- → DUPLICATE

This should be more-or-less fixed after bug 1579984, or at least not so bad. Can you retest in Nightly?

Flags: needinfo?(code)
Attached image bug_in_ff_73_0.jpg

This screen illustrates the problem in FireFox 73 that has not yet been solved by Nightly 75.0a1.

@Jeff Gilbert: I did test it with Nightly 75.0a1 (2020-02-16): Unfortunatelly, the fix of bug 1579984 made this problem here worse:

In Nightly 75.0a1, Firefox now always uses the slow GPU for the WebGL context and never switches to the fast one.

I created a new test that you can find here:

http://www.sy2002.de/firefox-test/qnice.html

Try it with Nightly 75.0a1: You will always have a low framerate (e.g. 3 FPS). Also using the Mac's activity monitor you will notice, that there is never a switch to the fast GPU. It will always use the slow GPU (even when reloading).

Now try it with the official Firefox 73.0: It will show a slow framerate (e.g. 3 FPS) and when you reload it will use the fast GPU context (that has been created in the meantime). See also bug_in_ff_73_0.jpg for a visual explanation.

Expected behaviour:

Just like Chrome, FireFox should "sense" that WebGL is being in place and then switch to the fast (discrete) GPU.

Flags: needinfo?(code) → needinfo?(jgilbert)
Version: 73 Branch → 75 Branch

Have you tested in recent Chrome Canary? Chrome announced that they would also leave powerPreference:default webgl contexts on the low-power GPU:
https://www.khronos.org/webgl/public-mailing-list/public_webgl/1912/msg00001.php

Very shortly, any content that needs to run on the dGPU will need to request powerPreference:high-performance.

Flags: needinfo?(jgilbert) → needinfo?(code)

Thank you for sharing this announcement on the Khronos mailinglist with me - indeed I was not aware of this.

After your hint, I did test with today's Chrome Canary version 82.0.4061.2: It now behaves like Firefox Nightly.

So you are absolutely right then with your chosen way forward and therefore I need to change my WebGL app to actually request powerPreference:high-performance: This was a very helpful hint; thank you for taking the time helping me.

Flags: needinfo?(code)

Thanks for filing a bug! I'm happy to help.

Not really sure what the best label for this is, but I think INVALID (aka not a bug) is closest. (it used to be a bug though, which was kind of fixed?)

Resolution: DUPLICATE → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: