Closed
Bug 593700
Opened 14 years ago
Closed 14 years ago
CPU usage spikes when accelerated
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: nmaier, Unassigned)
References
Details
(Keywords: regression)
Regression range: Good nightly dc2939f2640d (2010-09-02) BAD nightly 4b879b793eb6 (2010-09-03) Steps: * Open e.g. Addons Manager (having some extensions installed) in a tab * Watch the UI consume (almost) an entire CPU core while about:addons is visible Alternative Steps: * Type something into the awesome bar * Watch the UI consume (almost) an entire CPU core while the result list is populated (drawn) Before regression: * Only minor CPU work/usage visible Seems to only happen when using some HW acceleration?! Win XP seems unaffected, Win7 with a basic theme or aero theme is affected. Some about:support Application Basics Firefox 4.0b6pre Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre Graphics Adapter Description ATI Radeon HD 3600 Series Vendor ID 1002 Device ID 9598 Adapter RAM 512 Adapter Drivers aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version 8.732.0.0 Driver Date 5-4-2010 Direct2D Enabled true DirectWrite Enabled true
Updated•14 years ago
|
blocking2.0: --- → ?
This looks like a build without d3d enabled, and could be what I was seeing as well with just d2d. We should figure out what's causing it.. Nils, can you grab the latest nightly (which should have d3d enabled by default), and see if the problem goes away?
Reporter | ||
Comment 2•14 years ago
|
||
Yep, the latest nightly initially "fixes" this to some extend. Having only about:addons open and visible there is still a baseline CPU load of 8 - 10% (Having a Quad core, this translated to 32-40% single core usage). So it's certainly not perfect. (I don't remember the about:addons implementation doing any high-speed polling that might cause this base load by itself). Usage, however, feels smooth again; scrolling is smooth again. Having some gfx-heavy website open (tested bild.de) said base load is by far lower. Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Layers Enabled 1/1 Direct3D 9 When I disable layers.accelerate-all, then the full-blown spikes reappear. GPU Accelerated Layers Enabled 0/1
Reporter | ||
Comment 3•14 years ago
|
||
hg bisect'ed this to: http://hg.mozilla.org/mozilla-central/rev/6854b075f70f
Reporter | ||
Comment 5•14 years ago
|
||
It seems to me the biggest performance regression originates from ShouldRetainTransparentSurface always returning PR_FALSE in D2D as GetTextQualityInTransparentSurfaces always returns TEXT_QUALITY_BAD: http://hg.mozilla.org/mozilla-central/rev/6854b075f70f#l1.8 http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxD2DSurface.h#60 I tried always returning PR_TRUE, which caused far less CPU load. ~33% load on the UI thread core instead of 90-100%. But 33% is still bad enough :p I quick time-sampled the process using AMD CodeAnalyst against a build of the first affected changeset, 6854b075f70f, having D2D/DirectWrite enabled but not the D3D layer. Some of the most interesting bits follow. Please note that CodeAnalyst computes the percentage of "total session samples" against all CPU cores (4 in this case) and incl. the "idle" process, hence this number seems a bit low. Process Name 64-bit Timer samples xul.dll 23.65 atidxx32.dll 1 16.39 d3d10_1core.dll 1 13.24 ntoskrnl.exe 1 7.6 ntdll.dll 7.29 d3d10_1core.dll: CS:EIP Symbol + Offset 64-bit Timer samples 0x6fa9c008 D3D10CoreCreateDevice1 1 92.09 0x6fa9bed0 D3D10CoreGetSupportedVersions 1 1.29 0x6fa975b5 NO SYMBOL 1 0.29 3 functions, 727 instructions, Total: 1303 samples, 90.24% of samples in the module, 1.62% of total session samples xul.dll: CS:EIP Symbol + Offset 64-bit Timer samples 0x5ece4669 BoxBlurVertical 9.09 0x5f3e5a90 _moz_cairo_matrix_transform_point 6.6 0x5ece44ad BoxBlurHorizontal 6.16 3 functions, 63 instructions, Total: 543 samples, 21.85% of samples in the module, 0.67% of total session samples ntdll.dll: CS:EIP Symbol + Offset 64-bit Timer samples 0x76f32210 RtlLeaveCriticalSection 32.64 0x76f32250 RtlEnterCriticalSection 29.11 0x76f3e068 RtlInitUnicodeString 18.67 3 functions, 64 instructions, Total: 616 samples, 68.60% of samples in the module, 0.76% of total session samples ntoskrnl.exe: CS:EIP Symbol + Offset 64-bit Timer samples 0xfffff80002c023d0 ExAllocatePoolWithTag 1 9.01 0xfffff80002ad84e0 KeAcquireInStackQueuedSpinLockAtDpcLevel 1 8.89 0xfffff80002c030b0 ExFreePoolWithTag 1 8.64 0xfffff80002ad7b60 KeWaitForMutexObject 1 7.13 4 functions, 126 instructions, Total: 269 samples, 8.48% of samples in the module, 0.33% of total session samples
Reporter | ||
Comment 6•14 years ago
|
||
Cannot reproduce these CPU spikes any longer in recent nightlies (the hardware or drivers haven't changed). That is with layers.accelerate-all turned off and on (D2D only/D2D + D3D). Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre from http://hg.mozilla.org/mozilla-central/rev/5588c9796f0b
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•14 years ago
|
blocking2.0: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•