699025 - GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL context creation with AA

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Christian Holler (:decoder)]

Attachment: Backtrace with MOZ_GL_DEBUG_ABORT_ON_ERROR=1

When using my own Firefox debug build with mesa llvmpipe rendering, I get an error on any WebGL demo (e.g.: http://www.chromeexperiments.com/detail/voxels-liquid/ ):

Mesa: User error: GL_INVALID_VALUE in RenderbufferStorageMultisample(samples)
WARNING: DrawFBO: Incomplete: file /home/decoder/LangFuzz/mozilla-central-browser/gfx/thebes/GLContext.cpp, line 1277
Framebuffer status: 8CD6
WARNING: Error resizing offscreen framebuffer -- framebuffer(s) not complete: file /home/decoder/LangFuzz/mozilla-central-browser/gfx/thebes/GLContext.cpp, line 1295
JavaScript warning: http://mrdoob.com/lab/javascript/webgl/voxels_liquid/js/Detector.js, line 9: WebGL: GL error 0x501 occurred during OpenGL context initialization, before WebGL initialization!
GL Context 0x7f16c9f99570 deleting resource 3, which doesn't exist!


Attached is a trace with MOZ_GL_DEBUG_ABORT_ON_ERROR=1.

This configuration works with the nightly builds though.

Comment 1

[Christian Holler (:decoder)]

Attachment: Backtrace from GLContext.cpp

Comment 2

[Christian Holler (:decoder)]

I have to correct myself, this configuration doesn't work in nightly anymore either. It could be a recent regression. While it worked with a nighly that I downloaded at 2011-10-13, it does not work with the nightly I downloaded yesterday. In the release build I just get:

Mesa: User error: GL_INVALID_VALUE in RenderbufferStorageMultisample(samples)

Comment 3

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

Does the error disappear if you set webgl.msaa-level=0  in about:config ?

Comment 4

[Christian Holler (:decoder)]

(In reply to Benoit Jacob [:bjacob] from comment #3)
> Does the error disappear if you set webgl.msaa-level=0  in about:config ?

Yes, it's working now. But it's significantly slower than it was before.

Comment 5

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

Slower than what exactly, i.e. what factor causes the speed difference?

Does webgl.msaa-level=1 work?

Can you attach the output of glxinfo?

Comment 6

[Christian Holler (:decoder)]

(In reply to Benoit Jacob [:bjacob] from comment #5)
> Slower than what exactly, i.e. what factor causes the speed difference?

Slower than the nightly debug build I downloaded 2011-10-13. I can provide you that tarball if that helps. In that build, the msaa-level thing doesnt influence the speed.

> Does webgl.msaa-level=1 work?

No.
 
> Can you attach the output of glxinfo?

Will attach.

Comment 7

[Christian Holler (:decoder)]

Attachment: Output of glxinfo

Comment 8

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

(In reply to Christian Holler (:decoder) from comment #6)
> (In reply to Benoit Jacob [:bjacob] from comment #5)
> > Slower than what exactly, i.e. what factor causes the speed difference?
> 
> Slower than the nightly debug build I downloaded 2011-10-13.

So here you're comparing "your own Firefox debug build" (comment 0) with a Nightly build, which is optimized? That would explain the speed difference. To check, you can paste the build config of your build as shown in about:buildconfig.

Is today's Nightly slower than the one you downloaded 2011-10-13?

> you that tarball if that helps. In that build, the msaa-level thing doesnt
> influence the speed.

That's because Antialiasing hadn't landed yet.

Comment 9

[Christian Holler (:decoder)]

(In reply to Benoit Jacob [:bjacob] from comment #8)

> Is today's Nightly slower than the one you downloaded 2011-10-13?

Yes. I was not comparing to my own build, but I was comparing a debug nightly that I downloaded 2011-10-13 vs. a debug nightly I downloaded yesterday. Both yesterday's debug and release nightlies are painfully slow while the debug nightly from 2011-10-13 is much faster.

Comment 10

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

Thanks, i understand now. It seems that you're hitting Bug 696590. It's a regression from the WebGL antialiasing patches, but we don't really understand it yet.

It's a separate bug anyway.

Comment 11

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

Attachment: Don't use more samples than the maximum

Comment 12

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 571343 [details] [diff] [review]
Don't use more samples than the maximum

Review of attachment 571343 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. I think I originally had something like this, but it fell by the wayside.

Comment 13

[Kelsey Gilbert [:jgilbert]]

Performance with GL debug mode decreased naturally after landing AA, as there's simply more to do than there was before. In GL debug mode, we glFinish() after every command to accurately link issued commands and errors. When drawing to the screen, debug-mode draw commands call three extra commands (which each call glFinish), and debug-mode read commands can end up calling glFinish around ten times.

Performance outside of GL debug mode should not be seriously compromised, however.

Comment 14

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

GL debug mode is not available in release builds such as Nightly, which Christian says he was using in comment 9. Likewise in Bug 696590. See that bug; it seems that we have a real performance regression with BasicLayers i.e. non-accelerated compositing. I can confirm it locally, too.

Comment 15

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/ef9b57cf2a7c

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/ef9b57cf2a7c

Please see https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound 

Thanks :-)