Closed Bug 824845 Opened 12 years ago Closed 1 year ago

Hardware acceleration hurts tabstrip paint times

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: vladan, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [Snappy:P1][Australis:P-])

Attachments

(1 file)

At MattN's suggestion, Avi compared tab-open animation paint times with hardware acceleration enabled and disabled:

https://bugzilla.mozilla.org/show_bug.cgi?id=738491#c79
(see attachment as well)

He found that hardware acceleration increases paint times by ~78% on a slow PC (AMD E-350) and ~96% on a fast PC (i7-3630qm)!

You can find the raw timings in the bug linked above. Additional timings reproduced below:

Fast PC + default theme + hardware acceleration ON:
-----------------------------------------------------

(6:14:00 PM) avih: Overall tab-open average (208 recorded frames): Interval: 15.6 Paint: 5.3
(6:14:00 PM) avih: Overall tab-close average (182 recorded frames): Interval: 17 Paint: 5.9

Fast PC + default theme + hardware acceleration OFF:
-----------------------------------------------------

(6:14:00 PM) avih: Overall tab-open average (269 recorded frames): Interval: 15.6 Paint: 2.7
(6:14:00 PM) avih: Overall tab-close average (259 recorded frames): Interval: 16.8 Paint: 2.5
Whiteboard: [Snappy:P1]
yes, the slowdown is known(see bug 633157)  The key is to find the specific primitives that trigger this.
Hmm.  I'm assuming this is D3D10 + D2D, yes?  Can you also try: D3D10, no D2D; and D3D9?

vsync might be hurting us here; we seem to be passing the flags to say ignore vsync, but who knows whether that's being honored.  Can you capture/show the actual raw paint times, and plot the distribution.  I assume 5.3/5.9 is just the average?  I'd be interested in seeing a histogram of the full set of per-frame values.
This is with clean profile with defaults on m-c:
gfx.direct3d.prefer_10_1 = true
gfx.font_rendering.directwrite.enabled = false
gfx.font_rendering.directwrite.use_gdi_table_loading = true

I don't think it's vsync. Both frame intervals and paint times are quite regular (except possibly for the first few frames of the animation, where paint times could be slightly higher, and frame intervals show some irregularity).

To verify it's not vsync, I set layout.frame_rate to 100 and got this for tab open (after several opens, the average at the bottom aggregates all previous open animations):

Tab open (Frame-interval / paint-processing):
12 / 5
8 / 2
4 / 2
13 / 5
9 / 4
11 / 5
9 / 4
11 / 4
10 / 4
9 / 4
10 / 4
10 / 4
11 / 4
9 / 4
10 / 4
11 / 5
9 / 4
10 / 4
10 / 4
11 / 5
12 / 5
7 / 4
11 / 5
9 / 4
10 / 4
11 / 4
Overall tab-open average (103 recorded frames): Interval: 10 Paint: 4.1

And after disabling "Use HW acceleration when available" (and restarting the browser and opening/closing few tabs, without tabstrip overflow):

Tab open (Frame-interval / paint-processing):
7 / 3
5 / 1
3 / 1
12 / 1
9 / 1
11 / 1
10 / 1
10 / 1
10 / 2
10 / 1
10 / 1
10 / 1
10 / 1
12 / 3
10 / 3
10 / 3
9 / 2
10 / 2
10 / 2
10 / 2
10 / 2
11 / 3
12 / 4
9 / 3
10 / 3
11 / 3
Overall tab-open average (207 recorded frames): Interval: 9.8 Paint: 2.4
Hmm... staying with HW accel enabled, but setting gfx.direct3d.prefer_10_1 = false, I get results similar to when HW accel is disabled (that's with i7-3630qm, using the integrated GPU HD4000).

How can I tell if HW accel is actually working?

Tab open (Frame-interval / paint-processing):
11 / 3
6 / 1
7 / 1
11 / 1
10 / 1
10 / 1
10 / 2
12 / 4
10 / 4
10 / 3
10 / 2
10 / 2
9 / 2
11 / 3
11 / 3
10 / 3
9 / 2
10 / 2
10 / 3
10 / 3
10 / 2
10 / 3
10 / 2
10 / 2
10 / 3
10 / 2
Overall tab-open average (336 recorded frames): Interval: 9.9 Paint: 2.4
Also, on my slow PC (AMD-E350 with internal GPU: Mobility Radeon HD 6310), there's no difference between D3D 9/10, but disabling HW accel improves paint times, especially once the animation "gets into the groove": after getting past the first few frames, paint times are about half with HW accel off:

HW accel on:

Tab open (Frame-interval / paint-processing):
11 / 11
38 / 20
26 / 13
14 / 12
15 / 14
14 / 12
11 / 10
12 / 10
16 / 11
15 / 11
18 / 10
16 / 12
15 / 10
15 / 9
16 / 10
Overall tab-open average (197 recorded frames): Interval: 18 Paint: 11.2


HW accel off:

Tab open (Frame-interval / paint-processing):
12 / 12
40 / 22
26 / 13
10 / 6
7 / 6
11 / 5
18 / 5
16 / 5
16 / 5
17 / 6
16 / 5
17 / 5
16 / 6
15 / 5
16 / 6
Overall tab-open average (233 recorded frames): Interval: 17.2 Paint: 7.5
Following vlad's request, I issued the tests, while verifying at about:support if d2d/d3d are enabled/disabled. Here are the results.
Note: There appear to be some variations between runs (I ran most of the tests more than once), but the variation is usually within about 10% for the same test.

- On the i7 laptop, disabling d2d also disables d3d (both 9 and 10, both with the inegrated gpu and with the external one).
- On the i7 laptop, preferring d3d9 disables d3d.
- On the AMD laptop, disabling d2d results in d3d9, even if prefer-d3d9=false.

i7-3630qm + HD4000:
-------------------
accel: off         : Interval: 15.6 Paint: 2.9
d2d: yes, d3d: 10  : Interval: 15.7 Paint: 5
d2d: yes, d3d: none: Interval: 15.9 Paint: 4.8

d2d: yes, d3d: 10,   gfx.content.azure.enabled=false: Interval: 15.8 Paint: 5.3
d2d: yes, d3d: none, gfx.content.azure.enabled=false: Interval: 15.8 Paint: 5


i7-3630qm + gt650m:
-------------------
accel: off         : Interval: 15.5 Paint: 2.8
d2d: yes, d3d: 10  : Interval: 15.7 Paint: 4.5
d2d: yes, d3d: none: Interval: 15.7 Paint: 4.3


AMD E-350 + 6310:
-----------------
accel: off         : Interval: 16.6 Paint: 6.4
d2d: yes, d3d: 10  : Interval: 17.8 Paint: 11
d2d: yes, d3d: 9   : Interval: 17.7 Paint: 8.3
d2d: no,  d3d: 9   : Interval: 17.5 Paint: 8.1
Following vlad's suggestion, here's a patch to ease profiling by repeating tab open/close animation and printing overall averages of frame-intervals/paint-times.

- Apply patch v6 from bug 820167, then apply the attached patch and build.
- Set browser.newtab.url = about:blank
- Set browser.tabs.animationLogging.enabled = true
- Hide navigation toolbar
- Restart Firefox
- Open 2 new tabs using the keyboard, move the mouse away from the browser.

- Close the last tab with CTRL-W
  -> A sequence of 15 times open+close tab will be performed

- Open the error console
  -> The last lines of the last 2 entries should be tab-open statistics and tab-close statistics.
  -> Previous entries are frame-intervals/paint-times per tab open/close.

- To repeat for fresh stats, close the error console, open a new tab, close the last tab.

- On an i7-3630qm + HD4000 win7-64 system with aero theme, paint-times average (for both tab open and tab close) are about half when HW acceleration is disabled (about 2.7ms), compared to when it's enabled (about 5ms).

- Number of repeats can be set by changing repeat_count at the patch.
- Default delay between tab open/close is 0ms, but can be changed via repeat_delay at the patch.
- To prevent switching to new tab when adding one (thus excluding content rendering performance impact on animation and profiling noise), set repeat_switchToNewTab at the patch to false. However, with about:blank as newtab url, performance impact seems negligible.
Profile of 50 x tab-open and 50 x tab-close:

HW accel On (D3D10 + D2D): http://people.mozilla.com/~bgirard/cleopatra/#report=67894f4073fef6f6e91f214958745c20025a3faf

Paint::PresShell::Paint - 20.6%
nsCSSRendering::PaintGradient - 10.8%
nsCSSRendering::PaintBorder - 1.5%



HW accel Off: http://people.mozilla.com/~bgirard/cleopatra/#report=ff4d9de9fb83bec5373af7095ddbb640fd791a1f

Paint::PresShell::Paint - 8.4%
nsCSSRendering::PaintBorder - 1.7%
nsCSSRendering::PaintGradient - 1.2%

...
Try making nsCSSRendering::PaintGradient a no-op and retry the hw accel timings?
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #9)
> Try making nsCSSRendering::PaintGradient a no-op and retry the hw accel
> timings?

That brings down the average paint time to around 3.4 ms. A considerable improvement compared to 5 ms, but still not s fast as non accelerated.
FYI, there's a revised patch for tab-animation-repeats which applies cleanly to recent m-c and ux branches. See bug 837885 comment #3 for the revised patch and suggested test procedure.
Keywords: perf
Blocks: 633157
Whiteboard: [Snappy:P1] → [Snappy:P1][Australis:P?][Australis:M?]
Whiteboard: [Snappy:P1][Australis:P?][Australis:M?] → [Snappy:P1][Australis:P5][Australis:M?]
(In reply to Avi Halachmi (:avih) from comment #11)
> FYI, there's a revised patch for tab-animation-repeats which applies cleanly
> to recent m-c and ux branches. See bug 837885 comment #3 for the revised
> patch and suggested test procedure.

Just for the record, TART replaces any such previous patch. See bug 907911.
Avi, now that TART has landed in talos, can you re-run this to see what difference it makes and what we could do about it?

We will probably need to get a gfx person on this bug.
Flags: needinfo?(avihpit)
Yes, apparently enabling HWA still slows down tab animation on low-end systems.

These are some values MattN recently collected on his Atom n450 netbook:

20 runs                   Simple Open             Simple Close		
                       Half   All    Error     Half   All    Error
m-c 20130820 HWA off   11.34  17.5   85.9      8.79   12.13  3.99
UX  20130820 HWA off   15.15  25.65  83.22     18.61  22.64  9.35

m-c 20130820 HWA on    38.91  54.51  117.21    32.91  41.46  8.39
UX  20130820 HWA on    21.57  36.36  103.45    28.33  36.93  7.82

The most important value to look at is "half" since it's the closest here* to representing pure gfx performance.

Enabling D2D makes frames x3-x4 slower on m-c and ~30% slower on ux. D2D is now enabled by default on this Atom machine with the latest Intel gfx drivers (this apparently changed during the last few months).

* Even more pure would be the half/all values of iconFade-Dpi1, but this test was added to Matt's talos-tart after these values were taken, and it still hasn't made it into the official talos and TART. See bug 911431.

Matt, could you please confirm that these numbers are HWA on/off, and how was it controlled? i.e. using the config UI, or using preferences? Also, was D3D (9/10) enabled on any of those?
Flags: needinfo?(avihpit) → needinfo?(mnoorenberghe+bmo)
Adding some data copied from bug 911431 comment 6 (there's some further analysis there):

On AMD E350 (low end):

default (d3d/d2d off):
icon-close-DPI1.half            Average (5): 7.81 stddev: 0.26
iconFade-close-DPIcurrent.half  Average (5): 7.03 stddev: 0.42

And with D2D forced:
d2d:forced -> d3d10 on
icon-close-DPI1.half            Average (5): 25.17 stddev: 2.24
iconFade-close-DPIcurrent.half  Average (5): 17.61 stddev: 2.47


And here are somewhat representative lists of intervals for these cases:
D2D:off, D3D: off:
icon-close-DPI1.raw:           60.2   14.5   25.2   12.1   11.2   11.2   11.0   11.4   11.2   7.1   11.3   5.3   5.3   6.6   5.4   5.3   8.6   4.9   5.1
iconFade-close-DPIcurrent.raw: 8.2   8.3   9.3   7.9   8.2   7.8   8.1   7.7   8.3   7.6   8.1   7.4   7.9   7.3   7.6   7.3   7.2   9.3   7.1   7.6   7.1   7.9   8.1   7.9   6.7   6.7   6.7   6.3   5.5   6.1   4.9

D2D:on, D3D:10:
icon-close-DPI1.raw:           63.4   29.0   35.5   29.4   33.3   20.0   17.4   14.3
iconFade-close-DPIcurrent.raw: 14.8   16.8   16.6   16.1   16.3   16.2   16.5   15.5   16.5   16.9   19.4   17.9   15.7   11.2   10.7


So the throughput with HWA off is more than twice as fast for tab animation than with HWA on (iconFade is the purest: 7ms/frame vs 18).
(In reply to Avi Halachmi (:avih) from comment #14)
> Matt, could you please confirm that these numbers are HWA on/off, and how
> was it controlled? i.e. using the config UI, or using preferences? 

HWA was blacklisted on the device for the video card drivers initially and then I updated the drivers to ones which weren't blacklisted. I'm not sure it's fair to compare these since there could have been major changes in the drivers.

> Also, was D3D (9/10) enabled on any of those?

D3D 10 is on when HWA is on
Flags: needinfo?(mnoorenberghe+bmo)
AFAICT this isn't affecting Australis heavily anymore at this point, so it doesn't need to be tracked. If I'm wrong, please correct me.
Whiteboard: [Snappy:P1][Australis:P5][Australis:M?] → [Snappy:P1][Australis:P-][Australis:M?]
Depends on: 940977
Whiteboard: [Snappy:P1][Australis:P-][Australis:M?] → [Snappy:P1][Australis:P-]
Severity: normal → S3

Unable to reproduce in current versions.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: