Closed Bug 1028859 Opened 10 years ago Closed 9 years ago

[e10s] WebGL slow on e10s window

Categories

(Core :: Graphics: CanvasWebGL, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
tracking-b2g backlog
Tracking Status
e10s ? ---

People

(Reporter: alice0775, Assigned: jgilbert)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: meta, perf)

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/366b5c0c02d3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140622030203

WebGL is slow on e10s window
Steps To Reproduce:
1. Open https://webglsamples.googlecode.com/hg/aquarium/aquarium.html
   --- observe fps
2. Restart browser
3. Open e10s window
4. Open https://webglsamples.googlecode.com/hg/aquarium/aquarium.html
   --- observe fps

Actual Results
fps on e10s window  is much less than the fps on normal window.
fps of e10s window is 30-50% of normal window.
Graphics
--------

Adapter Description: ATI Radeon HD 4300/4500 Series
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50
Device ID: 0x954f
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16492)
Driver Date: 4-29-2013
Driver Version: 8.970.100.1100
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
It's going to stay slow until we update the compositing path for e10s.
Blocks: e10s-gfx
No longer blocks: fxe10s
tracking-e10s: --- → ?
Keywords: perf
Hi Jeff, do we have a bug open on updating the compositing path for e10s from comment 2? I just tried on a Macbook Pro, 15" w/ Retina. I can get 60 FPS w/ and w/o e10s until 4000 fish. Then I get about 40 FPS with e10s and 60 FPS without e10s.
Flags: needinfo?(jgilbert)
(In reply to Mason Chang [:mchang] from comment #3)
> Hi Jeff, do we have a bug open on updating the compositing path for e10s
> from comment 2? I just tried on a Macbook Pro, 15" w/ Retina. I can get 60
> FPS w/ and w/o e10s until 4000 fish. Then I get about 40 FPS with e10s and
> 60 FPS without e10s.

Bug 1066280 is half the problem. We don't have a bug yet for the second half.
Flags: needinfo?(jgilbert)
No longer depends on: 1066280
Depends on: 1077722
blocking-b2g: --- → backlog
Blocks: 1100487
Assignee: nobody → jgilbert
Nom'ing for retriage. This bug was e10s-tracking=+ but Luke says this bug is critical for Mozilla's games initiative and should block Aurora.
Milan, sounds like we need to be able to share textures across processes for this to be acceptably fast. Do you have a plan for that?
Flags: needinfo?(milan)
As in the firm schedule?  No.  WebGL resources are on GDC and once that clears out, we should be able to spend more time on other things.  May still happen along the way, but it isn't quite the first in line.
Flags: needinfo?(milan)
We're doing some media related testing over the next few weeks, juan can we sneak webgl demos in with that looking for issues?
Flags: needinfo?(jbecerra)
(In reply to Alice0775 White from comment #0)
>
> fps on e10s window  is much less than the fps on normal window.
> fps of e10s window is 30-50% of normal window.

Just to confirm these numbers, we recently updated a talos tool to compare e10s vs non e10s results (compare.py at the talos repo).

It indicates that the talos glterrain test (in ASAP mode = vsync off) is about 3x slower in e10s compared to than non e10s results.

Sample:

> $ python compare.py --compare-e10s --rev 0189941a3fd5 --pgo --verbose --branch Firefox --platform Win7 --master-revision 0189941a3fd5 --print-graph-url
>
>     test      Master     gmean  stddev points  change      gmean  stddev points  graph-url
> Win7:
> ...
> :( glterrain              4.9 +/-  2% (4#)  [+280.5%]      18.8 +/-  1% (4#)    http://graphs.mozilla.org/graph.html#tests=[[325,1,47],[325,1,25]]
What is the ASAP mode exactly? It disables vsync on requestAnimationFrame, or?
Yes, it disregards vsync intervals and tries to render the frames as soon as possible, while not blocking on swapinterval where applicable.
How does one enable that?
open about:config , change layout.frame_rate to 0
blocking-b2g: backlog → ---
Blocks: 1144120
Depends on: 1144906
Flags: needinfo?(jbecerra)
I encountered a similar behavior on Firefox 42.0a1 (2015-07-16) e10s window, using Ubuntu 14.04 32-bit with the following WebGL animation: http://madebyevan.com/webgl-water/
The browser response time was delayed with about 4 seconds in a e10s window compared with a non-e10s window where the interaction commands were applied almost instantly.

Testing with the WebGL sample from Description, I did not notice a difference between e10s and non-e10s windows.

Based on the above mentioned should I track this issue for all platforms or should I file a new one?
Flags: needinfo?(jgilbert)
I believe this bug should be marked fixed - at least for Windows. I tested on both the URL from comment 0 and the talos WebGL test, and on both of those e10s WebGL performance seem to be pretty much the same as non-e10s - on Windows.

Jeff, should this be marked FIXED? How much is bug 1077722 blocking this?

As for comment 15, I believe there's another bug open for WebGL perf on Linux, But I don't recall its number right now. Jeff?
I can confirm that the problem is no longer existing.

Performance progression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7720cbbe62e&tochange=c4d1692d88ee

Fixed by: c4d1692d88ee	Jeff Gilbert — Bug 1144906 - Add accel E10S backend for WebGL compositing. - r=jrmuizel,mattwoodrow,nical,sotaro
Yeah, this is done.
Slow WebGL on Linux is just a lack of hardware accel being enabled.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(jgilbert)
Resolution: --- → FIXED
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #15)
> I encountered a similar behavior on Firefox 42.0a1 (2015-07-16) e10s window,
> using Ubuntu 14.04 32-bit with the following WebGL animation:
> http://madebyevan.com/webgl-water/
> The browser response time was delayed with about 4 seconds in a e10s window
> compared with a non-e10s window where the interaction commands were applied
> almost instantly.
> 
> Testing with the WebGL sample from Description, I did not notice a
> difference between e10s and non-e10s windows.
> 
> Based on the above mentioned should I track this issue for all platforms or
> should I file a new one?

Please file a new one, thanks!
(In reply to Jeff Gilbert [:jgilbert] from comment #19)

> Please file a new one, thanks!

Filed Bug 1184859
You need to log in before you can comment on or make changes to this bug.