Closed
Bug 696590
Opened 14 years ago
Closed 13 years ago
WebGL antialiasing patches (bug 615976) + BasicLayers = slow on certain linux/nvidia systems, even with AA turned off
Categories
(Core :: Graphics: CanvasWebGL, defect)
Core
Graphics: CanvasWebGL
Tracking
()
RESOLVED
WORKSFORME
mozilla12
People
(Reporter: azakai, Assigned: jgilbert)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
340 bytes,
text/html
|
Details | |
2.67 KB,
patch
|
bjacob
:
feedback+
|
Details | Diff | Splinter Review |
http://oos.moxiecode.com/js_webgl/xwing/index.html
is a very cool WebGL game of an X-Wing fighter. It works great on FF7, but there is a disturbance in the force on Nightly/FF10 where it is extremely slow and unplayable.
Reporter | ||
Updated•14 years ago
|
Blocks: infer-perf-regress
Reporter | ||
Updated•14 years ago
|
the issue seems to occur starting with firefox beta (ff 8). i tried aurora, nightly, beta, and release (ff7) as well and only ff7 is perfectly fluid.
Graphic driver details:
Adapter DescriptionNVIDIA GeForce GTX 560
Vendor ID10deDevice ID1201Adapter RAM1024
Adapter Driversnvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version8.17.12.8538
Driver Date9-22-2011
Adapter RAM (GPU #2)Unknown
Adapter Drivers (GPU #2)Unknown
Direct2D Enabledtrue
DirectWrite Enabledtrue (6.1.7601.17563)
ClearType ParametersClearType parameters not found
WebGL RendererGoogle Inc. -- ANGLE (NVIDIA GeForce GTX 560) -- OpenGL ES 2.0 (ANGLE 0.0.0.774)
GPU Accelerated Windows1/1 Direct3D 10
Reporter | ||
Comment 2•14 years ago
|
||
I'm on Linux with NVidia drivers over here. For me it is smooth on Release, Beta and Aurora, and problematic only on Nightly.
Comment 3•14 years ago
|
||
Any particular reason why this is filed against the JS engine? Has someone profiled it already?
Reporter | ||
Comment 4•14 years ago
|
||
I initially filed it in JS because I suspected it was related to TI (having seen similar things there). But that could easily be wrong.
Reporter | ||
Comment 5•14 years ago
|
||
Testcase. More details and other bug modifications in 1 minute.
Reporter | ||
Comment 6•14 years ago
|
||
I think my initial guess was wrong - this looks like a WebGL canvas issue. Attached is a testcase that I believe suffers from the same problem as the URL.
STR:
1. Load the testcase.
2. Do control-shift-K to pop open the web console. It will open extremely slowly (takes 1 second on my laptop) and non-smoothly. Likewise when doing the same key combo to close it (and other stuff like switching tabs).
If the line with getContext() is commented out, the problem will vanish - opening and closing the console will be very smooth. So the existence of a WebGL context on the canvas seems to be the issue.
I didn't do a reduction on the X-Wing URL here, instead I noticed that the same problem occurs on http://syntensity.com/static/ammo.html (the symptoms look identical so assume it is the same issue), which I then reduced to the testcase.
I have been running the URL in the last paragraph almost every day recently, which leads me to conclude that the regression must be very very recent. My guess is that the first affected Nightly is the 21st or 22nd. Might be one or two earlier, though, I am not 100% sure when I updated.
Assignee: general → nobody
No longer blocks: infer-perf-regress
Component: JavaScript Engine → Canvas: WebGL
QA Contact: general → canvas.webgl
Comment 7•14 years ago
|
||
That timeframe would match when we enabled anti-aliasing (Bug 615976). On low-end hardware that by itself can explain slowness; on higher-end hardware like average NVIDIA cards it shouldn't make a big difference, but this was a massive code change so one never knows.
If you go to about:config and set webgl.msaa-level=0, does that fix the problem?
- if yes, then your issue is really an issue with anti-aliasing
- if no, then we can't conclude much as even with webgl.msaa-level=0, the antialiasing patches changed a lot of stuff. So in that case, can you try archived tinderbox builds before and after Bug 615976 landed?
Component: Canvas: WebGL → JavaScript Engine
Reporter | ||
Comment 8•14 years ago
|
||
Changing the pref doesn't have any effect.
The regression does *not* appear on the Nightly from 10-20, which is rev 78932:311fdb9b38b7
The regression *does* appear on the Nightly from 10-21, which is rev 79005:2afc252b4d39
And bug 615976 landed as revisions 78967:17c58be07034 to 78975:bf09dbe3fcd7 which is indeed in that range.
As a sanity check I also confirmed that there is no change in JavaScript performance on the URL in comment 6 with a shell testcase of the same code.
Moving to Component:Canvas WebGL, that seems most likely now I think.
Component: JavaScript Engine → Canvas: WebGL
Keywords: regression
Comment 9•14 years ago
|
||
Does layers.acceleration.force-enabled have any effect on the slowness you're experiencing?
Can you paste the contents of the Graphics section in about:support when it's slow?
Can you profile Firefox when it's slow?
I'm not experiencing any slowness here with my linux x86-64 / debian wheezy / nvidia quadro fx 880m / 275 driver series, with and without layers acceleration.
Component: Canvas: WebGL → JavaScript Engine
Comment 10•14 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #9)
> Does layers.acceleration.force-enabled have any effect on the slowness
> you're experiencing?
Note: you need to restart firefox for this to take effect.
Comment 11•14 years ago
|
||
accidentally changed component back.
Component: JavaScript Engine → Canvas: WebGL
Reporter | ||
Comment 12•14 years ago
|
||
Interesting, switching layers.acceleration.force-enabled to true and restarting fixes this for me.
about:support shows
Graphics
Adapter Description
NVIDIA Corporation -- GeForce 9300M GS/PCI/SSE2
Driver Version
3.3.0 NVIDIA 260.19.06
WebGL Renderer
NVIDIA Corporation -- GeForce 9300M GS/PCI/SSE2 -- 3.3.0 NVIDIA 260.19.06
GPU Accelerated Windows
0/1
This is exactly the same output both when fast in the 10/20 Nightly and when slow in the 10/21 Nightly. So I guess I am unaccelerated on both (I've been unaccelerated all this time?), but unaccelerated rendering changed somehow.
Comment 13•14 years ago
|
||
Yes, you've been unaccelerated all this time: layers acceleration is not yet enabled by default, see bug 594876, we're currently blocked on a rel-eng issue, see bug 684165, which we hope to be fixed in time to enable GL layers in firefox 11.
WebGL + BasicLayers is always a losing combination but it's not clear to me why AA makes it worse: perhaps Jeff G knows.
Meanwhile, if you could profile it, that would be very helpful.
Summary: WebGL X-Wing is much slower on Nightly → WebGL antialiasing + BasicLayers = slow on certain linux/nvidia systems
Updated•14 years ago
|
Summary: WebGL antialiasing + BasicLayers = slow on certain linux/nvidia systems → WebGL antialiasing patches (bug 615976) + BasicLayers = slow on certain linux/nvidia systems, even with AA turned off
![]() |
||
Comment 14•14 years ago
|
||
Sounds like we need a separate bug on comment 1, right? Did one get filed?
Comment 15•14 years ago
|
||
Indeed, comment 1 needs a separate bug, but only its author can do it in a useful way, as investigating it will require more information from him (for starters, have him bisect or profile it).
Alon: looking forward to a profile :)
Assignee | ||
Comment 16•14 years ago
|
||
This removes an unnecessary glFlush and restructures control path for MOZ_X11+MOZ_EGL_XRENDER_COMPOSITE to remove a glFinish when unsuccessful.
I don't know in what cases we use MOZ_X11+MOZ_EGL_XRENDER_COMPOSITE, but in that case, it also looks like below those changes, around line 1220, eglWaitNative() might slow things down, when run. In this case, we call glFinish(), and then not long later call eglWaitNative(), which is basically assuring that all native graphics calls are executed before subsequent GL calls. However, I think this is pretty necessary until we have double-buffering, or more work on bug 697831.
Attachment #573469 -
Flags: feedback?(bjacob)
Assignee | ||
Comment 17•14 years ago
|
||
The relevant part to AA is that with the msaa pref set to 0, we should see effectively identical performance to pre-AA.
Assignee | ||
Comment 18•14 years ago
|
||
Actually, this could be caused by slow access with glGetInteger() and kin. I will look into minimizing this, but it should only even be a problem when you're running many draw calls.
However, if I understand this bug correctly, merely the presence of a WebGL context on a page causes significant losses in smoothness/responsiveness to the web console, among other things?
Reporter | ||
Comment 19•14 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #18)
> However, if I understand this bug correctly, merely the presence of a WebGL
> context on a page causes significant losses in smoothness/responsiveness to
> the web console, among other things?
That's correct. The STR in comment 6 are basically just to open a page that creates a WebGL context on a canvas, and then painting the page is extremely slow (for example, when opening the web console).
Comment 20•14 years ago
|
||
Comment on attachment 573469 [details] [diff] [review]
Misc fixes to improve perf in BasicLayers
Review of attachment 573469 [details] [diff] [review]:
-----------------------------------------------------------------
The X11+EGL combo is only used on Meego at the moment.
Desktop linux (what this bug was originally reported against) uses GLX, not EGL.
Attachment #573469 -
Flags: feedback?(romaxa)
Attachment #573469 -
Flags: feedback?(bjacob)
Attachment #573469 -
Flags: feedback+
Reporter | ||
Comment 21•14 years ago
|
||
I ran oprofile on my machine at home where this bug occurs. The results are 70% of time spent in libnvidia-glcore.so.260.19.06, 2% in libcairo.so.2.11000.0, and 1% in nvidia_drv.so.
Any update on the patch here? The last event seems to be a request for feedback from romaxa.
Comment 22•14 years ago
|
||
Comment on attachment 573469 [details] [diff] [review]
Misc fixes to improve perf in BasicLayers
Bah, by now jgilbert is the big specialist of these things. But he has already landed several related fixes, so I'm not sure if this is still needed.
Attachment #573469 -
Flags: feedback?(romaxa)
Reporter | ||
Comment 23•14 years ago
|
||
I tested that patch now. It doesn't seem to have an effect, even with it WebGL is still basically unusable on this machine, 1 fps on everything.
Reporter | ||
Comment 24•14 years ago
|
||
(In reply to Alon Zakai (:azakai) from comment #23)
> I tested that patch now. It doesn't seem to have an effect, even with it
> WebGL is still basically unusable on this machine, 1 fps on everything.
I should have also said, WebGL works fine in Chrome and Opera, so this isn't a system-wide problem or something with the graphics driver. It's a FF problem that started about when this bug was filed on Nightly.
Comment 25•14 years ago
|
||
Tentatively assigning to Jeff but this seems hard to reproduce; Jeff had a theory that maybe it was some getIntegerv call being slow (due to lack or client-side caching).
Assignee: nobody → jgilbert
Comment 26•14 years ago
|
||
Hm, note that Alon originally reported this on Windows. Have you tried disabling layers accel on your windows/nvidia machine? (Mine is borked at the moment)
Comment 27•14 years ago
|
||
Alon: since you profiled it, can you say if a particular GL function is showing up high on the profile? For once, it may be worth profiling this in a non-optimized build so that functions don't get inlined. The slowdown is so big that it should still be dominant on a non-optimized debug build.
Reporter | ||
Comment 28•14 years ago
|
||
Sorry if I marked it as Windows at first, all I have is a Linux machine.
Toggling layers.acceleration.disabled doesn't have an effect on the problem.
If it helps, I can bring this laptop to the MV office.
The only profile information is what I posted before - the NVidia closed source driver doesn't seem to have the right symbol information for oprofile to pick out individual functions. (I see individual functions in FF code but not NVidia.)
Comment 29•14 years ago
|
||
Sorry, I got confused by comment 1.
layers.acceleration.disabled doesn't have an effect on linux because there, layers acceleration is disabled by default. What would have an effect there, is layers.acceleration.force-enabled.
It's no big deal that the nvidia driver doesn't have symbols: we call GL functions through our own wrappers in gfx/gl/GLContext.h. If you make them __attribute__((noinline)), they will show up in profiles.
Reporter | ||
Comment 30•13 years ago
|
||
This problem is now resolved for me :) It must have been fixed in one of the recent nightlies. (Benoit did mention to me that they had an idea about the cause here and how to fix it, I guess that is in another bug?)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → mozilla12
Version: unspecified → Trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•