Last Comment Bug 699025 - GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL context creation with AA
: GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL con...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: mozilla10
Assigned To: Benoit Jacob [:bjacob] (mostly away)
:
Mentors:
Depends on: 696590
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-02 05:54 PDT by Christian Holler (:decoder)
Modified: 2011-11-03 13:07 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Backtrace with MOZ_GL_DEBUG_ABORT_ON_ERROR=1 (11.64 KB, text/plain)
2011-11-02 05:54 PDT, Christian Holler (:decoder)
no flags Details
Backtrace from GLContext.cpp (8.69 KB, text/plain)
2011-11-02 05:56 PDT, Christian Holler (:decoder)
no flags Details
Output of glxinfo (18.01 KB, text/plain)
2011-11-02 06:37 PDT, Christian Holler (:decoder)
no flags Details
Don't use more samples than the maximum (1.94 KB, patch)
2011-11-02 08:47 PDT, Benoit Jacob [:bjacob] (mostly away)
jgilbert: review+
Details | Diff | Review

Description Christian Holler (:decoder) 2011-11-02 05:54:40 PDT
Created attachment 571312 [details]
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) 2011-11-02 05:56:34 PDT
Created attachment 571314 [details]
Backtrace from GLContext.cpp
Comment 2 Christian Holler (:decoder) 2011-11-02 06:02:57 PDT
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) 2011-11-02 06:09:42 PDT
Does the error disappear if you set webgl.msaa-level=0  in about:config ?
Comment 4 Christian Holler (:decoder) 2011-11-02 06:13:51 PDT
(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) 2011-11-02 06:24:28 PDT
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) 2011-11-02 06:37:04 PDT
(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) 2011-11-02 06:37:38 PDT
Created attachment 571321 [details]
Output of glxinfo
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2011-11-02 06:41:33 PDT
(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) 2011-11-02 06:51:01 PDT
(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) 2011-11-02 08:08:18 PDT
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) 2011-11-02 08:47:47 PDT
Created attachment 571343 [details] [diff] [review]
Don't use more samples than the maximum
Comment 12 Jeff Gilbert [:jgilbert] 2011-11-03 01:02:00 PDT
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 Jeff Gilbert [:jgilbert] 2011-11-03 01:24:57 PDT
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) 2011-11-03 06:15:52 PDT
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) 2011-11-03 07:57:20 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/ef9b57cf2a7c

Note You need to log in before you can comment on or make changes to this bug.