User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0 Build ID: 20120129021758 Steps to reproduce: I regularly check https://webglsamples.googlecode.com/hg/aquarium/aquarium.html as a test of WebGL speed and functionality when trying Aurora and Nightly builds Win XP SP3 Adapter Description Mobile Intel(R) 965 Express Chipset Family Vendor ID8086 Device ID2a02 Adapter RAM Unknown Adapter Driver sigxprd32 Driver Version 6.14.10.5218 Driver Date 1-13-2010 Vendor ID (GPU #2) 8086 Device ID (GPU #2) 2a03 Adapter RAM (GPU #2) Unknown Adapter Drivers (GPU #2) Unknown Driver Version (GPU #2) 6.14.10.5218 Driver Date (GPU #2) 1-13-2010 WebGL Renderer Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family) -- OpenGL ES 2.0 (ANGLE 0.0.0.809) GPU Accelerated Windows 2/2 Direct3D 9 Actual results: I cannot pinpoint an exact date, but for a while now WebGL does not seem to run as fast as it used to - I used to get about 15fps all the time. Now however, this has dropped to 7 or 8fps - this occurs even with a clean profile Expected results: I would expect WebGL performance as development continues would remain the same or (ideally) improve
WebGL Firefox 10 is still getting 15fps although WebGL sometimes does not seem to initialise correctly
Maybe a ANGLE upgrade slowed things down. Someone from the graphics team may be able to point out dates where ANGLE was upgraded. Then test http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ around that date.
Jon, it would be incredibly useful if you could bisect this using archived Nightly builds found at: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ Kevin, while it's possible that a ANGLE update would regress WebGL performance, it's also possible that the culprit is in our WebGL implementation per se, or in adjacent gfx code. Let's just bisect this for now.
I also note this regression. Windows XP 64 SP2, WebGL Aquarium : Fx 10 : ~60 FPS Fx 13 : 1~2 FPS Description de la carte ATI Radeon HD 4600 Series ID du vendeur 0x1002 ID du périphérique 0x9490 RAM de la carte Unknown Pilotes de la carte ati2dvag Version du pilote 8.930.0.0 Date du pilote 12-5-2011 Rendu Web GLGoogle Inc. -- ANGLE (ATI Radeon HD 4600 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963) Fenêtres avec AC 1/1 Direct3D 9
(In reply to Benoit Jacob [:bjacob] from comment #3) > Jon, it would be incredibly useful if you could bisect this using archived > Nightly builds found at: > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ > > Kevin, while it's possible that a ANGLE update would regress WebGL > performance, it's also possible that the culprit is in our WebGL > implementation per se, or in adjacent gfx code. Let's just bisect this for > now. I should be able to do this this weekend - what builds should I be looking at? mozilla-central builds from the 2012/01 2012/02 folders?
Yes, the mozilla-central builds.
I have noticed the slowness first with Inspector's 3D View (embedded Tilt); after some experimenting in my setup (Fx 12.0a2 32-bit on Windows 7 64-bit, Mobile Intel 965 Express -blocked, only Direct3D 9 available-) I found it also happens with other WebGL demos and got STR and a workaround: the problem manifests only when the WebGL application is started with a maximized window, and it doesn't when started from a restored window. I have yet to try starting the WebGL application from a fullscreen window (cannot test with Inspector's 3D View due to bug 694000, bug 705197 and because keyboard shortcuts for Inspector's buttons are not recognized in fullscreen). Nevertheless, when the WebGL application is started from a restored window it remains fast when it is maximized or fullscreened afterwards; conversely, when it is started from a maximized window it remains slow if the window is restored or fullscreened afterwards. In my setup the problem manifests with all my 24 add-ons enabled, and with all of them manually disabled (one by one) as well; however, if you do Help->Restart with Add-ons Disabled... the problem does not manifest. Hope this helps...
Forgot to mention, I can reproduce the described Restored/Maximized window dance with a new profile as well.
Maybe duplication of Bug 725747
Regression window(m-c) Last good: http://hg.mozilla.org/mozilla-central/rev/3c1cdbbea964 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207010203 First bad: http://hg.mozilla.org/mozilla-central/rev/2b61af9d18ee Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207023403 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c1cdbbea964&tochange=2b61af9d18ee Regression window(m-i) Last good: http://hg.mozilla.org/integration/mozilla-inbound/rev/e2db006298c2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206185103 First bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/fa92500f4ad2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206191607 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e2db006298c2&tochange=fa92500f4ad2 Triggered by: Bug 720467
I was just about to start trying to pin down where it went bad.... looks like I don't need to now?
Jon: comment 10 is conclusive that the regression is caused by the patches from bug 720467, but that implies that it's a regression in Firefox 13, not in Firefox 12 as you originally reported. If you are positive that there's a regression in Firefox 12 already, then comment 10 is talking about a separate thing and you own bisecting would then still be useful.
The regression found by comment 10, caused by bug 720467, is quite possibly/probably bug 725747, which has a patch pending review.
It seems that this slowness is caused by Angle. Inspector's 3D view started when browser is maximized: In Firefox 11: Fluid In Current m-c: sub 1FPS In Current m-c with webgl.prefer-native-gl true: Fluid I can also confirm Comment 7 Inspector's 3D view started when browser is not maximized: In Firefox 11: Fluid In Current m-c: Fluid In Current m-c with webgl.prefer-native-gl true: Fluid Tested with Radeon Mobile 6370 On Windows 7 64bit with 32bit builds of Firefox
OK - last good nightly build for me is the one from 26th Jan which was still version 12. WebGL on all subsequent builds is almost half as fast
according Comment 15,
This problem happens if layers.prefer-d3d9 = true; Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/7cdb5f5d38c6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126093130 Slow http://hg.mozilla.org/mozilla-central/rev/a82c9700c673 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126151450 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7cdb5f5d38c6&tochange=a82c9700c673 Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/9effde68bac5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126091747 Slow http://hg.mozilla.org/integration/mozilla-inbound/rev/fccccb47213e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126092751 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9effde68bac5&tochange=fccccb47213e Triggered by fccccb47213e Jeff Gilbert — Bug 721205 - Add correct logic for enabling BGRA readPixels for GLES - r=bjacob
So this is a couple of ANGLE bugs: http://code.google.com/p/angleproject/issues/detail?id=293 http://code.google.com/p/angleproject/issues/detail?id=294 This bug also severely impacts performance on d3d10 as well, though d3d9 should be being hit even harder. Try build at: https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282
I don't think this is a ANGLE (only) problem, because Aurora and Nightly has the same ANGLE version .963 http://www.kamibu.com/demos/cloth-simulation/ Aurora (12.0a2) = fast Nightly (13.0a1) = slow The only different I can see is gfx.direct3d.prefer_10_1 Aurora = gfx.direct3d.prefer_10_1 not exist Nightly = gfx.direct3d.prefer_10_1 is always true and cannot set to false (switching always back to true after restart) Google Inc. -- ANGLE (NVIDIA GeForce GT 240) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
Created attachment 598019 [details] [diff] [review] Patch 1: Enforce readPixels format/type spec This is an ANGLE bug: http://code.google.com/p/angleproject/issues/detail?id=293
Created attachment 598021 [details] [diff] [review] Patch 2: Expose BGRA as ANGLE fast-path This is an ANGLE bug: http://code.google.com/p/angleproject/issues/detail?id=294
Both patches together are running on try at: https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282
(In reply to MrX1980 from comment #19) > I don't think this is a ANGLE (only) problem, because Aurora and Nightly has > the same ANGLE version .963 > > http://www.kamibu.com/demos/cloth-simulation/ > Aurora (12.0a2) = fast > Nightly (13.0a1) = slow > > The only different I can see is gfx.direct3d.prefer_10_1 > Aurora = gfx.direct3d.prefer_10_1 not exist > Nightly = gfx.direct3d.prefer_10_1 is always true and cannot set to false > (switching always back to true after restart) > > Google Inc. -- ANGLE (NVIDIA GeForce GT 240) -- OpenGL ES 2.0 (ANGLE > 1.0.0.963) I believe this is bug 726396, which new appears to be distinct from this d3d9 layers bug.
Try build is back up to speed - performing well as it used to :)
Comment on attachment 598021 [details] [diff] [review] Patch 2: Expose BGRA as ANGLE fast-path Review of attachment 598021 [details] [diff] [review]: ----------------------------------------------------------------- What should be committed to upstream ANGLE?
Also: since these patches are to our copy of ANGLE, it is very important to add them as gfx/angle/*.patch files and mention them in gfx/angle/README.mozilla. Otherwise, if for some reason they're not accepted upstream, we'd lose them the next time we sync.
(In reply to Jeff Gilbert [:jgilbert] from comment #20) > Created attachment 598019 [details] [diff] [review] > Patch 1: Enforce readPixels format/type spec > > This is an ANGLE bug: > http://code.google.com/p/angleproject/issues/detail?id=293 As I explained in Issue 293, I don't believe this change is correct.
(In reply to Jeff Gilbert [:jgilbert] from comment #21) > Created attachment 598021 [details] [diff] [review] > Patch 2: Expose BGRA as ANGLE fast-path > > This is an ANGLE bug: > http://code.google.com/p/angleproject/issues/detail?id=294 I would consider accepting this patch. I don't believe it should rely on the previous patch. Ideally the approach in mainline would be as described in Issue 295 (http://code.google.com/p/angleproject/issues/detail?id=295), but this is likely better a better value for default IMPLEMENTATION READ FORMAT/TYPE until we get there.
Perhaps the biggest question though, is why is the ReadPixels path now being taken? It certainly wasn't before as we have not changed this area of ANGLE. In general read-pixels is not a well-optimized path in ANGLE, and likely will never be the best path. I thought that the ReadPixels path wasn't required under ANGLE (with the d3d9-share handles, etc). Note that we also provide support for ANGLE_framebuffer_blit which can do much more efficient copies.
(In reply to daniel-bzmz from comment #29) > Perhaps the biggest question though, is why is the ReadPixels path now being > taken? It certainly wasn't before as we have not changed this area of > ANGLE. In general read-pixels is not a well-optimized path in ANGLE, and > likely will never be the best path. I thought that the ReadPixels path > wasn't required under ANGLE (with the d3d9-share handles, etc). Note that > we also provide support for ANGLE_framebuffer_blit which can do much more > efficient copies. It was an issue with the patch for bug 720467, which will be fixed in bug 726396 which I will be uploading later today. There was some incorrect logic that was preventing the share handles from being used.
I would like to keep Patch 1's strict interpretation in our downstream version. It seems we've hit on a more strict implementation over at bug 728724, but it could be spurious.
Created attachment 599333 [details] [diff] [review] Patch 1.5: Add Patch 1 to ANGLE patches
Created attachment 599334 [details] [diff] [review] Patch 2.5: Add Patch 2 to ANGLE patches
(In reply to Jeff Gilbert [:jgilbert] from comment #31) > I would like to keep Patch 1's strict interpretation in our downstream > version. It seems we've hit on a more strict implementation over at bug > 728724, but it could be spurious. IMO ANGLE being less restrictive shouldn't have any impact on that, since ANGLE won't be used there...
Comment on attachment 599333 [details] [diff] [review] Patch 1.5: Add Patch 1 to ANGLE patches Review of attachment 599333 [details] [diff] [review]: ----------------------------------------------------------------- r=me but you also need to mention it in gfx/angle/README.mozilla
Comment on attachment 599334 [details] [diff] [review] Patch 2.5: Add Patch 2 to ANGLE patches Review of attachment 599334 [details] [diff] [review]: ----------------------------------------------------------------- r=me but you also need to mention it in gfx/angle/README.mozilla
(In reply to daniel-bzmz from comment #34) > (In reply to Jeff Gilbert [:jgilbert] from comment #31) > > I would like to keep Patch 1's strict interpretation in our downstream > > version. It seems we've hit on a more strict implementation over at bug > > 728724, but it could be spurious. > IMO ANGLE being less restrictive shouldn't have any impact on that, since > ANGLE won't be used there... It's not used there, but if ANGLE were equally restrictive, we would have caught these bugs earlier.
Created attachment 599770 [details] [diff] [review] Patch 1.5: Add Patch 1 to ANGLE patches Carrying r+ forward.
Created attachment 599773 [details] [diff] [review] Patch 2.5: Add Patch 2 to ANGLE patches Carrying r+ forward.
https://hg.mozilla.org/integration/mozilla-inbound/rev/59f92448d122 https://hg.mozilla.org/integration/mozilla-inbound/rev/ecab589f11f6 https://hg.mozilla.org/integration/mozilla-inbound/rev/388d3a2c8f12 https://hg.mozilla.org/integration/mozilla-inbound/rev/b4d48afb5859
https://hg.mozilla.org/mozilla-central/rev/59f92448d122 https://hg.mozilla.org/mozilla-central/rev/ecab589f11f6 https://hg.mozilla.org/mozilla-central/rev/388d3a2c8f12 https://hg.mozilla.org/mozilla-central/rev/b4d48afb5859
Will this be backported to firefox 12?
(In reply to Mathieu Pellerin from comment #42) > Will this be backported to firefox 12? Hopefully yes. The patches were fairly simple, so it should be relatively easy to backport.
Created attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA [Approval Request Comment] Regression caused by (bug #): 721205 User impact if declined: Severely compromised WebGL performance, mostly on WinXP. Testing completed (on m-c, etc.): On m-c and by QA. Risk to taking this patch (and alternatives if risky): Low risk: Problem is now well understood and the fix is simple. String changes made by this patch: None Asking bjacob for a r+ on this folded combinations of the previous patches to play it extra-safe.
Comment on attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA Regression was in 12, so only backporting to aurora is needed.
Comment on attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA Review of attachment 601152 [details] [diff] [review]: ----------------------------------------------------------------- Does seem to match. Side note: there is a severe bug... in bugzilla's diff viewer, when viewing the .patch files, it omits some of the line adds.
Comment on attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA In fact we also want that for beta! For bug 723444. [Approval Request Comment] Regression caused by (bug #): don't know... some ANGLE upgrade? jgilbert might know User impact if declined: WebGL very slow on certain/many Windows systems (I reproduceded on Windows XP in bug 723444). Testing completed (on m-c, etc.): It's on m-c already. I tested myself on beta on WinXP. Risk to taking this patch (and alternatives if risky): possibly introduce another WebGL perf regression. String changes made by this patch: none
Created attachment 601430 [details] [diff] [review] patch ready to land on beta Just set the a= field.
This shouldn't do anything to beta, since the patch it's built on (Bug 721205) landed in 12.
Comment on attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA Bug that needs beta review is Bug 727178.
Comment on attachment 601430 [details] [diff] [review] patch ready to land on beta This patch should be unnecessary, since we correctly use BGRA readpixels on ANGLE (though for invalid reasons) before the logic was corrected in the patch that landed on Fx12, exposing this regression. Changing this in ANGLE on Fx11/Beta shouldn't change anything, but it shouldn't fix anything either, I think.
(In reply to Jeff Gilbert [:jgilbert] from comment #51) > This patch should be unnecessary, since we correctly use BGRA readpixels on > ANGLE (though for invalid reasons) before the logic was corrected in the > patch that landed on Fx12, exposing this regression. Adding qawanted to see whether or not this regression is necessary on the latest Aurora 12 builds now that we've fixed bug 727178. Please re-nominate if not.
Specifically, they should check WebGL performance on WinXP. Without this patch, performance should be majorly impacted, since the patch that regressed this from bug 721205 landed on 12.
(In reply to Alex Keybl [:akeybl] from comment #52) > Adding qawanted to see whether or not this regression is necessary on the > latest Aurora 12 builds now that we've fixed bug 727178. Please re-nominate > if not. s/necessary/fixed/ (In reply to Jeff Gilbert [:jgilbert] from comment #53) > Specifically, they should check WebGL performance on WinXP. Without this > patch, performance should be majorly impacted, since the patch that > regressed this from bug 721205 landed on 12. Sorry, could you clarify whether you believe FF12 has poor performance with D3D9 without this patch? I took "This patch should be unnecessary" from your previous comment to mean we were unsure if it was necessary at all.
Perhaps I was too weak in my wording. This patch fixes a regression from a commit which hit Fx12. Since we are quite sure that this caused the regression, we can be quite sure that this fix is also needed on 12. That is, unless testing shows Fx12 perf was not degraded by the regression in question in this bug. In other words, Fx12 almost certainly needs this regression fix for those using d3d9 layers and ANGLE, which is mostly WinXP users. Without this backport, ANGLE performance will be (relatively severely) negatively impacted relative to the size of the canvas.
(In reply to Jeff Gilbert [:jgilbert] from comment #55) > That > is, unless testing shows Fx12 perf was not degraded by the regression in > question in this bug. Just pinged QA to verify whether the patch is necessary.
Tested on Windows XP latest FF 12 Aurora build (12.0a2) FPS: 8 with D3D9 Enabled FPS: 8 without D3D9 Adapter: NVIDIA Quadro FX 3450/4000 SDI WebGL Render: Google nc. -- ANGLE (NVIDIA Quadro FX 3450/4000 SDI) -- OpenGL ES 2.0 (ANGLE 1.0.0.963) GPU Accelerated Windows: 1/1 Direct 3D 9
Note: Above was tested with the aquarium at 50 fishes. Also tested this on Windows XP with the 2/7/2012 Aurora build of Firefox and saw the same performance in comment 57.
(In reply to Jason Smith from comment #58) > Note: Above was tested with the aquarium at 50 fishes. > > Also tested this on Windows XP with the 2/7/2012 Aurora build of Firefox and > saw the same performance in comment 57. How does this compare to trunk performance (should have been fixed) or FF 11 perf (before regression window)?
Testing on Windows XP with the current Nightly build FPS: 33 without d3d9 FPS: 33 with d3d9 Same machine specs as comment 57.
Testing on Windows XP with current Firefox Beta build: FPS: 34 with d3d9 FPS: 33 without d3d9 Same machine specs as comment 57.
Jeff - based upon QA's testing, is this still necessary on Aurora 12? If so, we'll approve so that you can land tomorrow.
(In reply to Alex Keybl [:akeybl] from comment #62) > Jeff - based upon QA's testing, is this still necessary on Aurora 12? If so, > we'll approve so that you can land tomorrow. Yes, this is still necessary. QA has nightly/13 and beta/11 at 33fps, while aurora/12 is at 8fps. This is also a low-risk patch, so landing should be uneventful.
Comment on attachment 601152 [details] [diff] [review] Fix ANGLE to readPixels better with BGRA [Triage Comment] Approved for Aurora 12 since this is a regression in that version.
https://hg.mozilla.org/releases/mozilla-aurora/rev/74c3521374f9
Is qawanted still needed on this bug? If so, what is the specific ask for QA?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #66) > Is qawanted still needed on this bug? If so, what is the specific ask for QA? As in Comment 4, probably WebGL Aquarium, or any WebGL demo with a large screen that displays framerate. The regression will cause extreme framerate reductions in relation to the size of the canvas. (near-fullscreen demos should be most affected) Complexity of demo doesn't matter too much; Aquarium with the least number of fishes should be tremendously slow with this regression. (pre-fix) Note that this is with D3D9 layers and ANGLE WebGL renderer.
If I understand comment 67 correctly, all that is needed at this point is fix verification. If that's that case, we can drop qawanted.
No one objected to my comment 22 so dropping qawanted. Please re-add if there's something specific needed.
Verified with Firefox 12 beta 2 on Windows XP having D3D9 enabled and Angle WebGL render - on the WebGL Aquarium demo (https://webglsamples.googlecode.com/hg/aquarium/aquarium.html) the frame rate is 30. Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0 Verified using Firefox 13 beta 2 that having D3D9 enabled and Angle WebGl render the fps is 30 (tested on https://webglsamples.googlecode.com/hg/aquarium/aquarium.html).
Has there been a regression here? Just updated Nightly to 30/06/2012 and aquarium page is running about half the speed. Not sure if this happened with this update or 1 or 2 days back as have not tested for a couple of days
File a new bug as it seems you have no problem in 13.0.1.
or
