The default bug view has changed. See this FAQ.

GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL context creation with AA

RESOLVED FIXED in mozilla10

Status

()

Core
Canvas: WebGL
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: decoder, Assigned: bjacob)

Tracking

Trunk
mozilla10
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Created attachment 571314 [details]
Backtrace from GLContext.cpp
(Reporter)

Comment 2

6 years ago
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)
(Assignee)

Comment 3

6 years ago
Does the error disappear if you set webgl.msaa-level=0  in about:config ?
(Reporter)

Comment 4

6 years ago
(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.
(Assignee)

Comment 5

6 years ago
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?
(Assignee)

Updated

6 years ago
Summary: GL Error leads to incomplete framebuffer with llvmpipe → GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL context creation with AA
(Reporter)

Comment 6

6 years ago
(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.
(Reporter)

Comment 7

6 years ago
Created attachment 571321 [details]
Output of glxinfo
(Assignee)

Comment 8

6 years ago
(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.
(Reporter)

Comment 9

6 years ago
(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.
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.
Depends on: 696590
Created attachment 571343 [details] [diff] [review]
Don't use more samples than the maximum
Attachment #571343 - Flags: review?(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.
Attachment #571343 - Flags: review?(jgilbert) → review+
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.
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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ef9b57cf2a7c
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 :-)
Assignee: nobody → bjacob
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.