1008571 - WebGL D3D11 Compositor has lower framerate than in Chrome when GPU bound

Status: NEW

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

Description

[vincent.arod]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140508004006

Steps to reproduce:

Following https://moztrap.mozilla.org/manage/case/8243/ case ; step 4

Open http://webglsamples.googlecode.com/hg/aquarium/aquarium.html




Actual results:

With the standard configuration (50 fishes) i get 20fps
If I do the same on the same laptop with Chrome ( v34.0.1847.131 m) i have a good 30fps, I can go through 2000 fishes to get 20fps



Expected results:

The result should be quite the same between firefox and chrome on the same configuration (dell latitude E6320 with windows 7 64bits)

Comment 1

[Jukka Jylänki]

I have this a quick peek in geckoprofiler.xpi, and on my Macbook Air running Windows 7 in bootcamp and current Firefox Nightly 32.0a1 (2014-05-09), I see 51% of time being spent inside the browser from glFinish. This suggests that this is related/caused by the same issue as this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1008216

Comment 2

[:Gijs (he/him)]

(In reply to Jukka Jylänki from comment #1)
> I have this a quick peek in geckoprofiler.xpi, and on my Macbook Air running
> Windows 7 in bootcamp and current Firefox Nightly 32.0a1 (2014-05-09), I see
> 51% of time being spent inside the browser from glFinish. This suggests that
> this is related/caused by the same issue as this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008216

Can you provide a link to the profile you obtained?

Comment 3

[Jukka Jylänki]

Here is one: http://people.mozilla.org/~bgirard/cleopatra/#report=a25307d7c7bdf0c46da30d39c35a3fc3b0562f73

Comment 4

[vincent.arod]

Attachment: ProfilAquariumWebGL.zip

to complete the profile given here is mine

Comment 5

[Kelsey Gilbert [:jgilbert]]

Please post your about:support Graphics section.

Comment 6

[vincent.arod]

about:support - section graphics :
Accélération graphique
Date du pilote	6-27-2013
Description de la carte	Intel(R) HD Graphics 3000
Direct2D activé	true
DirectWrite activé	true (6.2.9200.16492)
Fenêtres avec accélération graphique	1/1 Direct3D 10
GPU #2 active	false
ID du périphérique	0x0126
ID du vendeur	0x8086
Paramètres ClearType	Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400
Pilotes de la carte	igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
RAM de la carte	Unknown
Rendu WebGL	Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote	9.17.10.3223
windowLayerManagerRemote	false
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Comment 7

[u279076]

Setting this bug to NEW since it appears that Jukka confirms it.

Comment 8

[Jukka Jylänki]

I am seeing this exact same issue in another WebGL app on my Windows 7.1 with Intel HD 3000 Macbook Air laptop running bootcamp: 44.4% of all application time is spent inside rx::Renderer::Sync, called by glFinish <-SurfaceStream_TripleBuffer::SwapProducer <- mozilla::gl::GLScreenBuffer::Swap <- mozilla::gl::GLContext::PublishFrame <- mozilla::WebGLContext::PresentScreenBuffer C++ code in Firefox. Unfortunately the app is not public that I could post a link here.

The application runs at about 15fps on my laptop and I don't have a native version to run on my system, but profiling the same application on Android Nexus 4, I am getting solid 60fps.

The test was run on current Nightly channel Firefox 34.0a1 (2014-07-22)

Comment 9

[u480271]

I saw something similar when I profiled my webgl2 instancing demo. A lot of time was spent in SwapProducer. (I was running on native desktop GL, not ANGLE).

This leads me to think that we haven't disconnected WebGL from compositor properly and it's effectively running in lock-step. (Well that's what glFinish is going to do, isn't it?)

Comment 10

[Kelsey Gilbert [:jgilbert]]

(In reply to Dan Glastonbury :djg :kamidphish from comment #9)
> I saw something similar when I profiled my webgl2 instancing demo. A lot of
> time was spent in SwapProducer. (I was running on native desktop GL, not
> ANGLE).
> 
> This leads me to think that we haven't disconnected WebGL from compositor
> properly and it's effectively running in lock-step. (Well that's what
> glFinish is going to do, isn't it?)

Yes.

Comment 11

[Benoit Girard (:BenWa)]

Toronto is trying the approach from bug 1014815. It will tell us how much the glFinish is hurting. Then we can either take that patch or implement fencing for D3D similar to how we did for Gonk OGL.

Comment 12

[Benoit Girard (:BenWa)]

I've investigated this bug a bit more. I'm going to rename the bug and give better STR. The reason for this is that currently if you try the test case on something like my desktop with a Quadro you're going to be CPU bound and on some machine you're going to be GPU bound. So different people are likely to see different performance problems.

Let's focus when you're running D3D11 and you're GPU bound. In that case the SurfaceStream synchronization overhead is going to dominate the profiles. The STR are giving a file that should be GPU bound even on mid-range desktop dedicated GPUs. Therefore most people should see the same problem.

STR:
1) Run https://www.shadertoy.com/view/4dl3Wl (More clearly GPU Bound)

Otherwise the original demo will only be GPU bound on weak/old integrate intel GPUs.

In cases where were GPU bound Comment #9 applies and explains why we're behind Chrome on the same hardware.

Comment 13

[Benoit Girard (:BenWa)]

Actually the above test case is too GPU bound and doesn't do enough on the CPU. Finding a good test case seems to be mostly machine dependant. The best testcase to reproduce this bug is probably something that does 50-70% CPU + GPU loads. That way the lockstep behavior is maximized.