615800 - WebGL on Mac 10.6 fails to draw anything when GL layers are enabled, on a Geforce GT120

Status: RESOLVED INCOMPLETE

(Core :: Graphics: CanvasWebGL, defect, P5)

Description

[sheets]

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

None of these demos work in the latest Minefield on OS X 10.6:

http://www.khronos.org/webgl/wiki/Demo_Repository

Furthermore, the demos do not produce useful error messages and the browser appears to believe it is rendering the content correctly.



Reproducible: Always

Steps to Reproduce:
1. Download http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.0b8pre.en-US.mac64.dmg dated 30-Nov-2010 06:09
2. Go to any demo on the Khronos page.
Actual Results:  
The canvas is filled with upside down, empty page content.

Expected Results:  
Render the WebGL content.

I've turned on verbose messages. The validator is also on. Turning the validator off results in browser chrome corruption. No messages are sent to the error console.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/san-angeles/index.html seems to work ok for me on 10.6 with the Nov 30, 2010 nightly....

I wonder whether this depends on the exact graphics hardware...

bjacob, any idea what's going on here?

Comment 2

[Boris Zbarsky [:bzbarsky]]

sicking's demo seems to work ok for me as well.

Comment 3

[sheets]

Attachment: San Angeles Demo screenshot

Comment 4

[sheets]

NVIDIA GeForce GT 120:

  Chipset Model:	NVIDIA GeForce GT 120
  Type:	GPU
  Bus:	PCIe
  Slot:	Slot-1
  PCIe Lane Width:	x16
  VRAM (Total):	512 MB
  Vendor:	NVIDIA (0x10de)
  Device ID:	0x0640
  Revision ID:	0x00a1
  ROM Revision:	3386
  Displays:
Display Connector:
  Status:	No Display Connected
LED Cinema Display:
  Resolution:	1920 x 1200
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported
  Connection Type:	DisplayPort

Comment 5

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

Currently I can't reproduce any problem and have a NVIDIA card too. Suspecting a problem with GL layers on Mac. Can you please go to about:config and set layers.accelerate-none ? Alternatively, in Preferences, Advanced, General, uncheck the checkbox for hardware acceleration. You know that you've disabled it when in about:support under Graphics it says 0/1.

(In reply to comment #0)
> Furthermore, the demos do not produce useful error messages and the browser
> appears to believe it is rendering the content correctly.

In order to see WebGL warnings, you have to go to about:config and set the preference webgl.verbose.

I know this is hard to discover, that's being addressed in bug 615310.

> I've turned on verbose messages. The validator is also on. Turning the
> validator off results in browser chrome corruption.

OK, will look at it as soon as I get a hold of a mac. If anyone wants to help debug this: with a debug build, run with MOZ_GL_DEBUG environment variable defined, set webgl.shader_validator=false and run the San Angeles demo. Does it make a difference?

Comment 6

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

(In reply to comment #3)
> Created attachment 494306 [details]
> San Angeles Demo screenshot

Looks bad indeed, the main suspect would be a driver bug...

Does the problem exist in other browsers too (Chrome, Safari...) ?

Comment 7

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

(In reply to comment #5)
> I've turned on verbose messages.

Sorry, didn't see this the first time. OK.

Comment 8

[sheets]

(In reply to comment #6)
> (In reply to comment #3)
> > Created attachment 494306 [details] [details]
> > San Angeles Demo screenshot
> 
> Looks bad indeed, the main suspect would be a driver bug...
> 
> Does the problem exist in other browsers too (Chrome, Safari...) ?

Chrome 9 and Webkit nightlies both run the demos flawlessly at ~60FPS on this machine.

Comment 9

[Joe Drew (not getting mail)]

Very interesting. It does work on my computer, which is an NVIDIA 330M on Snow Leopard.

I've got to echo Benoit's suggestion to try without hardware acceleration - as he says in comment 5, Preferences, Advanced, General,
uncheck the checkbox for hardware acceleration. You know that you've disabled
it when in about:support under Graphics it says 0/1.

Comment 10

[sheets]

(In reply to comment #5)
> Currently I can't reproduce any problem and have a NVIDIA card too. Suspecting
> a problem with GL layers on Mac. Can you please go to about:config and set
> layers.accelerate-none ? Alternatively, in Preferences, Advanced, General,
> uncheck the checkbox for hardware acceleration. You know that you've disabled
> it when in about:support under Graphics it says 0/1.

This appears to have no effect. I set layers.accelerate-none to true and layers.accelerate-all to false (also tried without toggling accelerate-all). about:support still reports 1/1 for GPU Accelerated Windows.

> (In reply to comment #0)
> > Furthermore, the demos do not produce useful error messages and the browser
> > appears to believe it is rendering the content correctly.
> 
> In order to see WebGL warnings, you have to go to about:config and set the
> preference webgl.verbose.
> 
> I know this is hard to discover, that's being addressed in bug 615310.
> 
> > I've turned on verbose messages. The validator is also on. Turning the
> > validator off results in browser chrome corruption.
> 
> OK, will look at it as soon as I get a hold of a mac. If anyone wants to help
> debug this: with a debug build, run with MOZ_GL_DEBUG environment variable
> defined, set webgl.shader_validator=false and run the San Angeles demo. Does it
> make a difference?

I'll look at this next.

Comment 11

[sheets]

(In reply to comment #10)
> (In reply to comment #5)
> > Currently I can't reproduce any problem and have a NVIDIA card too. Suspecting
> > a problem with GL layers on Mac. Can you please go to about:config and set
> > layers.accelerate-none ? Alternatively, in Preferences, Advanced, General,
> > uncheck the checkbox for hardware acceleration. You know that you've disabled
> > it when in about:support under Graphics it says 0/1.
> 
> This appears to have no effect. I set layers.accelerate-none to true and
> layers.accelerate-all to false (also tried without toggling accelerate-all).
> about:support still reports 1/1 for GPU Accelerated Windows.

Silly me. A browser restart is required >_<. With 0/1 for acceleration, I get perfect demo results.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fwiw, I also have a 330M (makes sense; we both have recent macbook pros, I bet).

The GeForce GT 120 sounds like a MacPro from last year or early this year or an early 2009 24" imac.  Joe, have we got either one lying around?

Comment 13

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

(In reply to comment #11)
> Silly me. A browser restart is required >_<. With 0/1 for acceleration, I get
> perfect demo results.

Great, very interesting. To summarize:
 * with GL layers, you get messed up rendering
 * without GL layers, it works.

This could very easily be explained by us calling GL functions on the wrong GL context, when we are juggling between 2 different GL contexts (one for WebGL, one for the GL accelerated layer).

So I would really, really like to hear about the results of this being run on a debug build [*], with the environment variable MOZ_GL_DEBUG defined, so a command line like
   MOZ_GL_DEBUG=1 /path/to/firefox
(make sure you don't have any firefox already running, or use -P -no-remote)

 * If this crashes, then the above theory will be confirmed and a getting a call stack will then allow to fix this.

 * Otherwise, retry with MOZ_GL_DEBUG_ABORT_ON_ERROR instead, in case the graphics corruption might be revealed by a GL error.

[*] Debug builds are available there:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/

Comment 14

[sheets]

Attachment: MOZ_GL_DEBUG=1 on Minefield Debug Nightly

Comment 15

[sheets]

Attachment: MOZ_GL_DEBUG_ABORT_ON_ERROR=1 on Minefield Debug Nightly

Comment 16

[sheets]

Attachment: Minefield Debug Screenshot

Comment 17

[sheets]

It may be a totally unrelated bug but I also get a browser crash when running this test:

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/buffer-data-array-buffer.html

I will attach the debug output from this shortly.

Comment 18

[sheets]

Attachment: buffer-data-array-buffer.html crash

Comment 19

[sheets]

(In reply to comment #12)
> Fwiw, I also have a 330M (makes sense; we both have recent macbook pros, I
> bet).
> 
> The GeForce GT 120 sounds like a MacPro from last year or early this year or an
> early 2009 24" imac.  Joe, have we got either one lying around?

The host system is a MacPro from early-mid 2009.

Comment 20

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

(In reply to comment #18)
> Created attachment 494514 [details]
> buffer-data-array-buffer.html crash

This is just the JS program crashing, not Firefox crashing; this is known as bug 613306.

Comment 21

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

Boris, question for you:

(In reply to comment #14)
> Created attachment 494507 [details]
> MOZ_GL_DEBUG=1 on Minefield Debug Nightly

nsNativeModuleLoader::LoadModule("/Applications/MinefieldDebug.app/Contents/MacOS/components/libxpcomsample.dylib")
- load FAILED, rv: 80004005, error:
  <unknown; can't get error from NSPR>

Is this normal ??

Comment 22

[sheets]

This is still present in the FF4 RC1 that was just sent to nightly testers.

Build info:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

Built from:
http://hg.mozilla.org/releases/mozilla-2.0/rev/5f8f494a4c29

Comment 23

[George Wright (:gw280) (needinfo me!)]

Is this still happening?

Comment 24

[sheets]

Still happening in 9.0.1. Does not occur on general WebGL content in 11.0a2 (2012-01-13). On some applications, the cross-tab and cross-app buffer corruption is still present ( http://www.ashimagroup.net/demo/game/ooman/tutorial/ and http://www.ashimagroup.net/demo/recon/corner/ ). On other applications ( http://www.ashimagroup.net/demo/pano/mars/ ) the browser now crashes.

These may be separate bugs or Aurora flakiness, though.

Let me know if you'd like me to try other versions or flags.

Comment 25

[Kelsey Gilbert [:jgilbert]]

It sounds like this may have been fixed in 11, which is now Release.
If we can get confirmation, I'd like to mark this fixed.

Comment 26

[sheets]

Still in Firefox 11 Release and Aurora 13.0a2 (2012-03-25) with corrupted buffers and browser crashes.

Comment 27

[Kelsey Gilbert [:jgilbert]]

Is this still present?

Comment 28

[sheets]

I don't know if this is still present as I no longer have access to the machine that was presenting.

Comment 29

[Kelsey Gilbert [:jgilbert]]

Marking this incomplete until someone else has this hardware and can reproduce this.
If anyone can reproduce this, please reopen this bug.