Open Bug 620065 Opened 14 years ago Updated 1 year ago

Fluid dynamics simulator ALT MODE is slow

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect

Tracking

()

People

(Reporter: fry.kun, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101215 Firefox/4.0b8pre Alternate drawing mode at http://nerget.com/fluidSim/ causes the frame rate to go so low that the simulator is unusable. Xorg info: [ 29.057] X.Org X Server 1.9.1 Release Date: 2010-10-22 [ 29.057] X Protocol Version 11, Revision 0 [ 29.057] Build Operating System: x86-13 2.6.32-72.el6.bz634452.x86_64 [ 29.057] Current Operating System: Linux ***hostname*** 2.6.35.9-64.fc14.i686 #1 SMP Fri Dec 3 12:35:42 UTC 2010 i686 [ 29.058] Kernel command line: ro root=UUID=9050e366-*****-786f91264c39 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us quiet radeon.new_pll=0 [ 29.058] Build Date: 09 November 2010 08:15:10PM [ 29.058] Build ID: xorg-x11-server 1.9.1-3.fc14 [ 29.085] Current version of pixman: 0.18.4 Reproducible: Always Tested speeds: Fx (Dec 10 build, from http://nightly.mozilla.org/js-preview.html): * primary mode: 44-47 FPS * alternate mode: 3-15 FPS Same, using MOZ_ACCELERATED=11: * primary mode: 41-44 FPS * alternate mode: 2-10 FPS Chromium 8.0.560.0 (from http://repos.fedorapeople.org/repos/spot/chromium/fedora-14/): * primary mode: 35 FPS (no variation while moving the mouse) * alternate mode: 15-24 FPS (animation appears smooth, even at 15) I also tried Chromium with --disable-accelerated-compositing (it's apparently enabled by default), but no major variation in speed
Not JS, gfx -- right? /be
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Graphics
Ever confirmed: true
QA Contact: general → thebes
You tell me :) As far as I see, Chrome works a lot better in the same session/screen/driver/etc. Maybe the calls to gfx on Linux are not optimized..? Also ref. bug 508716
Konstantin, I was going by bug 508716 comment 58. /be
I meant you would know better - you know the system; I'm just a user.
Observations on windows 7: All with default resolution of 64, 10 solver iterations: FF With D2D: Primary mode: 60 fps Alternate mode: 35-40 fps, drops quickly during a lot of interaction FF Without D2D: Primary mode: 65 fps but it's blocky Alternate mode: 30 fps, also drops quickly with interaction Chrome 7: Primary mode: 55 fps, smooth like D2D Alternate mode: 45 fps, doesn't drop much with interaction I suspect this has to do with the cost of tessellating strokes in both Cairo and D2D. Much like the Lorenz chrome experiment.
That would be consistent with me not seeing the problem on Mac, for what it's worth. Do we have a tracking bug for all the perf issues to to stroke tesselation we're accumulating? :(
So.. is this bug going to just stay as "NEW" until Firefox 8 and then get closed because of no activity? Just saying, because this seems to be happening to too many bugs that I file...
(In reply to comment #7) > So.. is this bug going to just stay as "NEW" until Firefox 8 and then get > closed because of no activity? > Just saying, because this seems to be happening to too many bugs that I file... I can say it's not on the top of the priority list, no. For the GFX part of this, improving the stroking code is a complicated task, it's something that's being taken into account with the graphics layer redesign. However these cases are rare and don't have a high impact on user experience, so investing a lot to specifically improve demo's like this one in the current architecture seems like a questionable move to me.
Most specific case bugs point to a more generic problem. They might be very different issues, but here are some other indicators that something is not quite as fast as it should be: Asteroids bookmarklet from http://erkie.github.com/ Tested on https://mozilla.org -- on Firefox 4, input sometimes lags (some keypresses ignored or delayed). Especially if firing and moving around a lot. Don't see the problem on Chromium 11.0.679.0 (0) http://demos.hacks.mozilla.org/openweb/HWACCEL/ demo: Firefox 4 scores 1FPS Chromium scores 10FPS http://benfirshman.com/projects/jsnes/ demo: Firefox 4 shows ~40FPS, gameplay is laggy (smooth animation but too slow) Chromium shows ~58FPS, gameplay is obviously faster than Fx4 Note, I don't really care about any of these toys/demos by themselves, but they add up to sluggish performance overall.
(In reply to comment #9) > Most specific case bugs point to a more generic problem. They might be very > different issues, but here are some other indicators that something is not > quite as fast as it should be: > > Asteroids bookmarklet from http://erkie.github.com/ > Tested on https://mozilla.org -- on Firefox 4, input sometimes lags (some > keypresses ignored or delayed). Especially if firing and moving around a lot. > Don't see the problem on Chromium 11.0.679.0 (0) > > http://demos.hacks.mozilla.org/openweb/HWACCEL/ demo: > Firefox 4 scores 1FPS > Chromium scores 10FPS > > http://benfirshman.com/projects/jsnes/ demo: > Firefox 4 shows ~40FPS, gameplay is laggy (smooth animation but too slow) > Chromium shows ~58FPS, gameplay is obviously faster than Fx4 > > > Note, I don't really care about any of these toys/demos by themselves, but they > add up to sluggish performance overall. Yes, on Linux, Chrome uses a fast software rasterizer where ours(cairo) is much slower from what I know. Windows with D2D and Mac should have better results in all these cases. Hopefully when we have a new graphics layer the graphics performance situation on Linux will improve.
Neither of those last two testcases has to do with the issue in this bug. I have no idea about the asteroids one. For HWACCEL, btw, it sounds like you have a buggy XRender implementation. Good ones can give you a lot more than 1fpx (think 30fps or more).
@Bas: I'm not planning to migrate to Windows or Mac, though :) And I'm also hoping things will improve. @Boris: Anything I can do about the buggy XRender? Which are the good ones?
Konstantin, I don't know offhand. Some people report good results using the nvidia proprietary driver; others report good results with ATI. This is something to talk to whoever writes your driver about....
That would be the open source radeon driver, then. So what you and Bas are saying that the driver is so bad that rendering everything in software is actually faster than using it??
Konstantin: Are those results with hardware acceleration enabled or not? Performance losses due to enabling acceleration should be fixed by bug 640082, but it again depends on what your driver supports. I've tested that on the official nvidia drivers and it works, fglrx doesn't support it though. Performance without hardware acceleration is more or less gated on how fast X can draw, which usually depends on the XRender implementation provided by your graphics drivers. Again, the official nvidia drivers seem to do quite a good job, more so than fglrx. Those are the only configurations I've personally tried.
Matt: I'm using radeon driver (OSS replacement of fglrx). I remember reading that it's been blacklisted, so there's no hardware acceleration. That said, the checkbox "use hardware acceleration when available" is enabled. Somewhat offtopic: from running GrafxBot, I only remember seeing what looked like canvas size errors, but maybe I'm wrong. In the past I've used fglrx with mixed results (kernel panics, hibernation/sleep issues, multimonitor problems), so as soon as radeon driver supported my card I switched to it and never looked back. AFAIK, it's still actively developed/maintained, so I hope there are bugs filed on it to get these issues sorted out..? If not, who should I ping to get the process going?
Konstantin, some XRender implementations actually do the work in software instead of using the hardware. If you have one of those, then yes, doing it in software on the client end would be faster, even when using the same software impl as Xrender (because it saves the client-to-X-and-back traffic). And to add insult to injury, the rasterizer those software XRender implementations tend to use is not only the same one as cairo (which is slow; see previous comments in this bug) but is also usually to be a pretty old version (hence even slower). So if you do in fact end up using the software XRender implementations, they tend to be _very_ slow. At least as of about 18 months ago, when I was still doing profiling on Linux. I can't tell you whether your driver is one of the ones that do this, but if you're seeing the 1fps thing when 3d acceleration is disabled in Firefox, chances are that it is. :(
I've filed a bug on radeon driver: https://bugs.freedesktop.org/show_bug.cgi?id=35579 They're checking out the HWACCEL software XRender issue. As for everything else, is the answer "wait for graphics layer redesign"?
Findings (for HWACCEL demo): * the demo is using a 640x7760 image as source and cutting it up into 640x485 chunks on the fly using drawImage * my hardware allows for up to 4096x4096 source image, so driver falls back to software rendering. Other (older) hardware allows only up to 2047x2047 source images. Question: should web developer be made aware of this (so they could optimize their code for hardware acceleration on the fly)? Or maybe Firefox should do something about it? Or do you think it's the driver's job? Note: I've made a copy of the demo on my laptop and changed the source image to be 1920x1940 - it's now falling back to software rendering for a different reason..
After commenting out the 2nd fallback (as per https://bugs.freedesktop.org/show_bug.cgi?id=27139#c11) the speed went up to 24FPS!! Still not 100% sure what's going on, but looks like there's some hope yet!
So if I understand it correctly, the fix is to change the repeat flag from RepeatNone to RepeatPad, can someone confirm if this makes sense?
Have you got a call stack for the Gecko operation which leads to RepeatNone in the driver?
No, I don't have a copy of the source code. The JS call is ctx.drawImage(img, 0, offset, 640, 480, 0, 0, 64, 48); in demo http://demos.hacks.mozilla.org/openweb/HWACCEL/ Or are you going to make me get all the source code, learn how to build it and debug it? :)
Firefox nightly builds have symbols. Distro builds probably also have debuginfo packages. But if it's drawImage, I think bug 468496 is what you want.
Okay, that's not so bad then. If you still want to get a stack trace, let me know how to get it from a nightly when hitting this call. Otherwise, I'll keep checking back on 468496
Just upgraded to Fedora 18/Firefox 18 and decided to try this benchmark again. Note: running on different hardware nowadays - Intel 8086:0116 with SNA acceleration Performance: primary mode - 60-70 FPS alt mode - ~50 FPS when nothing is drawn, ~3 FPS with lots of drawing activity, ~20 FPS after something is drawn and left to settle down Chromium 23: primary mode - 60-70 FPS alt mode - ~50 FPS when nothing is drawn or when settled down, 40-45 FPS with a lot of drawing activity
Still no progress on this, huh?
Original bug still stands -- alt mode is quite slow What's to be done about fixing it?
I've changed the OS to Fedora 20 with kernel 3.12.6-300.fc20.x86_64 (and arch i686 --> x64) Original benchmark (http://nerget.com/fluidSim/) results at high activity: Firefox: primary mode: 60-85 FPS alt mode: 3-6 FPS Chromium 27: primary mode: 84-85 FPS (extremely steady) alt mode: 64-65 FPS (also steady)
Both software & hardware acceleration methods are still slow on firefox, can easily drop alt mode to 2-3 FPS Chrome 37 very steady. With hardware accel, can't get below 80FPS in either mode
Severity: normal → S3

Reporter, are you still experiencing this issue?

Flags: needinfo?(fry.kun)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(fry.kun)
See Also: → 1864381
You need to log in before you can comment on or make changes to this bug.