Closed Bug 593700 Opened 14 years ago Closed 14 years ago

CPU usage spikes when accelerated

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect
Not set
critical

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
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?
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
Awesome. Looks like this is a regression from bug 579276.
Blocks: 579276
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
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
blocking2.0: ? → ---
You need to log in before you can comment on or make changes to this bug.