Closed Bug 699025 Opened 8 years ago Closed 8 years ago
_INVALID _VALUE in Renderbuffer Storage Multisample with llvmpipe on Web GL context creation with AA
11.64 KB, text/plain
8.69 KB, text/plain
18.01 KB, text/plain
1.94 KB, patch
|Details | Diff | Splinter Review|
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)
Does the error disappear if you set webgl.msaa-level=0 in about:config ?
(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.
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?
Summary: GL Error leads to incomplete framebuffer with llvmpipe → GL_INVALID_VALUE in RenderbufferStorageMultisample with llvmpipe on WebGL context creation with AA
(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.
(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.
(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
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/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
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.