611292 - Block software and non-GL2 OpenGL on OS X

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jarkko Oranen]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101110 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101110 Firefox/4.0b8pre

Firefox appears to work fine if run in 64-bit mode on Snow Leopard, but running it in 32-bit mode is unusably slow, with very noticeable lag when interacting with the UI. 

Window size seems to affect this, as the slowness is most noticeable when I have Firefox maximised on my secondary (1080p) display.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox/Minefield in 32-bit mode (by selecting the option via the "Get Info" dialog)
2. Make Firefox fullscreen on a large display (perhaps has to be secondary?)
3. Use Firefox as usual
Actual Results:  
Firefox is noticeably slow; even typing text in the URL bar is very laggy; It basically renders Firefox unusable in 32-bit mode on my computer.

Expected Results:  
This slowness does not appear in 64-bit mode.

Happens with a fresh profile on both Minefield and 4.0b7.

Hardware information:

Hardware Overview:

  Model Name:	MacBook
  Model Identifier:	MacBook2,1
  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.16 GHz
  Number Of Processors:	1
  Total Number Of Cores:	2
  L2 Cache:	4 MB
  Memory:	3 GB
  Bus Speed:	667 MHz

Graphics, displays:

Intel GMA 950:

  Chipset Model:	GMA 950
  Type:	GPU
  Bus:	Built-In
  VRAM (Total):	64 MB of Shared System Memory
  Vendor:	Intel (0x8086)
  Device ID:	0x27a2
  Revision ID:	0x0003
  Displays:
Color LCD:
  Resolution:	1280 x 800
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
BenQ G2410HD:
  Resolution:	1920 x 1080 @ 60 Hz
  Pixel Depth:	32-Bit Color (ARGB8888)
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported

Comment 1

[Wayne Mery (:wsmwk)]

Jarkko, If this a regression, can you identify dates for a smaller regression range?  Does it happen when started in safe mode? https://support.mozilla.com/kb/Safe+Mode

Comment 2

[Jarkko Oranen]

I suspect I would have to bisect nightlies from quite a long ago to find a more specific date for this, and I don't have time for that right now.

However, the problem seems to disappear if I run Firefox in safe mode. I didn't even think of that since I tested with a clean profile. What's the difference between a clean profile and safe mode?

Comment 3

[Frankie]

WFM in MBP Merom 2.2GHz, OS X 10.6.5. I mainly use the release build (3.6.12) but I installed 4.0b7, tried both 64 & 32 bit modes, and did not see any performance issues.

Comment 4

[Jarkko Oranen]

Huh, I just did some testing and removed everything Firefox-related from my computer (after backing up my profile, of course) and now the problem manifests even in safe mode. Maybe I had accidentally opened FF in 64-bit mode when I tested; though I'm pretty sure I didn't...

I'll try to find a version where this does not happen.

Comment 5

[Jarkko Oranen]

Scratch the safemode comment. That was just me typoing the switch... Today is not my day.

Anyway, I narrowed the problem down to between these two versions: 

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre WORKS (Built from http://hg.mozilla.org/tracemonkey/rev/f9a76b1ff3a3)

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20101001 Firefox/4.0b7pre does NOT work (Built from http://hg.mozilla.org/tracemonkey/rev/6ff07c1f4dc2)

(There didn't seem to be a mac build for the 30th? Or did I just miss it?)

Hope this helps. In both cases I downloaded the mac64.dmg and ran it in 32-bit mode, on a clean profile.

Comment 6

[Wayne Mery (:wsmwk)]

nice work!  does it fail also with most recent TM build?

perhaps same as one of these bugs https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&field0-0-0=short_desc&bug_severity=major&bug_severity=normal&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&resolution=FIXED&resolution=DUPLICATE&classification=Client%20Software&classification=Components&op_sys=Mac%20OS%20X&chfieldto=2010-11-25&chfield=[Bug%20creation]&query_format=advanced&chfieldfrom=2010-09-29%20&value0-0-1=perf&type0-0-0=anywordssubstr&value0-0-0=slow&field1-0-0=short_desc&product=Core&product=Firefox&field1-0-1=short_desc

Comment 7

[Jarkko Oranen]

Yep, still slow on today's TM build.

I can't really say if I'm hitting any of the bugs in the above query though.

Comment 8

[Jarkko Oranen]

I found out this problem has something to do with hardware acceleration. If I uncheck the "Use hardware acceleration when possible" in advanced settings, the lagginess in 32-bit mode goes away. Of course, performance without hardware acceleration is pretty bad (especially fast scrolling) but at least it's the same for both 32-bit and 64-bit modes.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The regression range in comment 5 includes this checkin:

  Joe Drew — Bug 580405 - Turn on OpenGL accelerated layer composition by
  default on OS X. r=vlad a=b

So that just flipped the default value of the preference comment 8 is about.

bjacob, care to take a look?

I wonder whether 10.5 shows the same performance problem....

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Jarkko's graphics card (vendor 8086 device 27a2) is a Intel GMA 945. It's not programmable hardware, it doesn't have programmable shaders, so it can't accelerate our Layers.

When we initialize GL layers, we load OpenGL 2 entry points from the library, which includes the functions to handle programmable shaders. So if OpenGL initialization works, then we have OpenGL 2, and we had been relying on the assumption that that meant that we have *accelerated* OpenGL 2.

So my suspiscion (this is just speculation) is that what's happening to Jarkko might be that in 32-bit mode, he might have some *software shaders* OpenGL 2 library making OpenGL initialization succeeding but actually using slow software shaders, while in 64-bit mode, OpenGL initialization fails as it should, giving him non-OpenGL rendering which is decently fast.

Jarkko: can you please go to about:support in 32-bit firefox and then in 64-bit firefox; at the bottom there's a "graphics" section, please paste here what it says.

Comment 11

[Jarkko Oranen]

It says the same in both modes (in 4.0b7, without acceleration enabled): 

Adapter Description 0x24000,0x20400 
Vendor ID 4000 
Device ID 4000 
Adapter RAM 
Adapter Drivers 
Driver Version
Driver Date
Direct2D Enabled false
DirectWrite Enabled false
GPU Accelerated Windows 0/1

With acceleration, the last line just changes to 1/1 OpenGL, in both modes.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #11)
> It says the same in both modes (in 4.0b7, without acceleration enabled): 
> 
> Adapter Description 0x24000,0x20400 

Ah, there we go:
http://developer.apple.com/library/mac/#DOCUMENTATION/GraphicsImaging/Reference/CGL_OpenGL/Reference/reference.html
0x24000 is "kCGLRendererIntel900ID: The Intel GMA 900 renderer."
0x20400 is "kCGLRendererGenericFloatID: The floating-point software renderer."

So I guess that the slowness is explained by the fact that, since your Intel GMA 945 card doesn't support OpenGL 2, it's using the fallback renderer 0x20400.

In any case we should just blacklist both 0x24000 and 0x20400. Patch coming.

The only thing that really puzzles me is that you report that it was fast on 64-bit code, using OpenGL (as your about:support info shows). Could it be that the 64-bit version uses a much more optimized software renderer? For example, SSE2 is available by default on 64-bit, so there are reasonable reasons why that would be the case. But I still don't think that we should allow using software OpenGL (we should get the same speed without OpenGL anyway, and also it's just too likely to be very slow at least in certain cases)

> Vendor ID 4000 
> Device ID 4000

These numbers are a bug in our code, I checked our source code getting these numbers on Mac and it's indeed wrong:
http://hg.mozilla.org/mozilla-central/file/22344f2229cc/widget/src/cocoa/GfxInfo.mm#l148
That however isn't what is causing you trouble --- these ids aren't currently used at all.

CC'ing Vlad.

Comment 13

[Wayne Mery (:wsmwk)]

bug 602739 also speculates of being a regression of bug 580405

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: blacklist software and non-GL2 hardware renderers on Mac

(didn't test it, will put on tryserver if r+)

Explanatory comment from the patch:

  // CGL reports a list of renderers, some renderers are slow (e.g. software)
  // and AFAIK we can't decide which one will be used among them, so let's implement this blocklist
  // by defaulting to BLOCKED_DEVICE, and unblocking when a non-blacklisted renderer is found.
  // The assumption that we make here is that the system will spontaneously use the best/fastest renderer in the list.
  // Note that the presence of software renderer fallbacks means that slow software rendering may be automatically
  // used, which seems to be the case in bug 611292 where the user had a Intel GMA 945 card (non programmable hardware).
  // Therefore we need to explicitly blacklist non-OpenGL2 hardware, which could result in a software renderer
  // being used.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I'd assume that any software for Mac assumes SSE2 is available, since it's available on all Intel processors ever shipped in Macs...

Comment 16

[Joe Drew (not getting mail)]

Comment on attachment 493574 [details] [diff] [review]
blacklist software and non-GL2 hardware renderers on Mac

>+        case kCGLRendererATIRadeonX1000ID: // slow

Actually, this is "can't render to non-power-of-two texture backed framebuffers", iirc.

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/mozilla-central/rev/ea40cb0cd218

Feel free to reopen if you still have trouble.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

Jarko, we've changed the way blacklisting works. It would be very helpful if you could retest your configuration with a nightly from today or later to see if Firefox has become slow again.

Comment 19

[Jarkko Oranen]

I tested with the latest nightly offered on nightly.mozilla.org, built from rev a896a9e237a0. Is that new enough?

For comparison, FF8b (my main browser at the moment) about:support says acceleration is blocked. In 32-bit nightly it says 0/1 windows accelerated, and in 64-bit nightly acceleration is apparently enabled since it says 1/1 (OpenGL)

However, I detect no noticeable slowdown in 64-bit mode. I'm only using a single fullhd monitor at this time though.