Flickering and rendering artifacts with OpenGL layers on Intel SandyBridge (Linux)

VERIFIED FIXED in mozilla17

Status

()

Core
Graphics
--
minor
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Robert Kaiser, Assigned: karlt)

Tracking

(Blocks: 1 bug)

Trunk
mozilla17
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
This may be similar to or the same as bug 687831, but the info there is not enough for me to determine that.

I used layers.acceleration.force-enabled=true to turn on OpenGL layers on my current Nightly build, and I get flickering of apparently most or all areas that are redrawn at any stage, and I get some interesting rendering artifacts of which I'll attach screen shots.

This is an openSUSE Factory (right now roughly equivalent with the just-released openSUSE 12.1) system with Intel SandyBridge (i7-2600K) graphics, here's some info on what I'm running:

> uname -a
Linux robert 3.1.0-2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux


about:support (Excerpt):

  Application Basics

        Name
        Firefox

        Version
        11.0a1

        User Agent
        Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111204 Firefox/11.0a1

[...]

  Graphics

        Adapter Description
        Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Desktop

        Driver Version
        2.1 Mesa 7.11.1

        WebGL Renderer
        Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Desktop  -- 2.1 Mesa 7.11.1

        GPU Accelerated Windows
        4/4 OpenGL
(Reporter)

Comment 1

6 years ago
Created attachment 579087 [details]
Screenshot 1: Scrolling

In this first screenshot, I scrolled a website one step down, so look for the artifacts at the bottom of the screen. when I move the mouse over the image, the whole artifact "line" disappears and things are normal again.
(Reporter)

Comment 2

6 years ago
Created attachment 579090 [details]
Screenshot 2: Bringing work space into view

The second screenshot was taken immediately after taking the first screenshot, going back to GIMP (on a different virtual desktop), telling it to take another screenshot, and switching back to the virtual desktop with Nightly on it. See that the artifact from scrolling before is gone, but now the toolbars at the top are mostly black. When I hover over them, they're back again.

Also, :hover effects (which are particularly frequent in my LCARStrek theme) seem to often be one step behind and sometimes an area, even possibly the whole content area goes blank and gets rendered only again when either the mouse is moved over some part of it or something else triggers repainting.
(Reporter)

Comment 3

6 years ago
I also saw my build swallowing 2-4 GB of additional RAM when that pref was enabled, unfortunately all going into "heap-unclassified" in about:memory.
(Reporter)

Updated

6 years ago
Blocks: 594876
No longer depends on: 594876
(Reporter)

Comment 4

5 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #3)
> I also saw my build swallowing 2-4 GB of additional RAM when that pref was
> enabled, unfortunately all going into "heap-unclassified" in about:memory.

That's down to ~500M additional RAM in current builds after recent patches that promised to reduce that problem as far as I remember from some MemShrink post.

The other effects seem to still be the same or very similar on kernel 3.2 and a build from 2011-01-14.

Comment 5

5 years ago
I have similar issues with intel ironlake. If layers is enabled the UI flickers everytime I click something. I don't seem to get any actual artifacts scrolling or anything though, just lots of flickering on UI elements.

Comment 6

5 years ago
For me there is no flickering, but same problem with scrolling (like on attached "Screenshot 1: Scrolling") on R600g and Mesa 8.0.1.
(Reporter)

Comment 7

5 years ago
(In reply to runetmember from comment #6)
> For me there is no flickering, but same problem with scrolling (like on
> attached "Screenshot 1: Scrolling") on R600g and Mesa 8.0.1.

R600g isn't Intel, it's ATI/AMD, right? Which driver are you using? Binary or open source?

Comment 8

5 years ago
R600g is FOSS driver. My config: https://bugzilla.mozilla.org/show_bug.cgi?id=731519#c1
(Reporter)

Comment 9

5 years ago
(In reply to runetmember from comment #8)
> R600g is FOSS driver. My config:
> https://bugzilla.mozilla.org/show_bug.cgi?id=731519#c1

OK, that driver AFAIK uses all the official kernel support, direct rendering library and Mesa stuff pretty much the same way the Intel driver does (which is what I'm using) - while the proprietary ATI/AMD and NVidia drivers might not, that's why I asked.

Us both seeing those problems might indicate that the bug is either in that open graphics stack or our interaction with it, which I guess is helpful info.

Comment 10

5 years ago
This affects me as well on Arch Linux x64 with the 3.2.9 Kernel, mesa 8.0, and Intel Ironlake graphics. I've observed the issue on FF 10 and 11 stable as well as nightly 14.

I would LOVE to get this figured out as it's the last thing keeping WebGl from working properly on my system. Please let me know if there's anything helpful in the way of logs or system info I can post.

Comment 11

5 years ago
I should have mentioned that like runetmember, I only experience the flickering, no artifacts.

Comment 12

5 years ago
same issue here (flickering + artifacts): 

VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller 
Driver: xf86-video-intel 2.18.0
Mesa: 8.0.2
libdrm: 2.4.33
xorg-server: 1.11.2
OS: Gentoo Linux
Severity: normal → minor
Is this really a minor issue? This stops us from enabling accelerated layer rendering on this *extremely* common chipset...

Comment 14

5 years ago
The title is not correct anymore. It does not apply to Sandy Bridge only (see Comment 12). 

For me (from the user perspective) it is not a minor issue since it really slows down some web pages. For example "command and conquer alliances" has about 1/10 of the fps when not having accelerated layering enabled. Corruptions with having it enabled are heavy, leaving the fox unusable. Need to move another window over ff to refresh the page. otherwise it seems to freeze. having empty entries in the address bar recommendations, etc.

Comment 15

5 years ago
What is the current status of this bug : has it been refiled at bugs.freedesktop.org to work with Intel people on it ?
Besides the title should be more generic, i.e. : "Flickering and rendering artifacts with OpenGL layers with Mesa drivers"
The reason why this bug isn't getting a lot of focus at the moment, is that we already know of bigger problems that need to be solved before GL layers can be enabled on Linux/x11. See the blockers of bug 594876. At least: not using xrender / x pixmaps anymore.

Comment 17

5 years ago
Just for the record : you may talk about Bug 738937 - Use Cairo image surfaces and shm PutImage instead of xrender on GTK/Linux
(In reply to Chris Lord [:cwiiis] from comment #13)
> Is this really a minor issue? This stops us from enabling accelerated layer
> rendering on this *extremely* common chipset...

I downgraded it from 'normal' because this is a problem with a configuration that 'non-supported'. (You need to force layers acceleration to overcome the blacklisting)

This certainly doesn't mean it's not a problem, and we certainly should fix it, but supported rendering paths come first.

Comment 19

5 years ago
I encounter the same scrolling glitches as described in #c1, plus some UI controls not refreshing (mostly text fields),
this is the GPU I own : http://www.notebookcheck.biz/Intel-Graphics-Media-Accelerator-GMA-4500MHD.11468.0.html
(linux x86_64, kernel 3.3.0,
xorg-x11-drv-intel-2.17.0-8.fc16.x86_64,
mesa-libGL-7.11.2-3.fc16.x86_64,
libdrm-2.4.30-1.fc16.x86_64,
xorg-x11-server-common-1.11.4-3.fc16.x86_64)

That said, the WebGL experience is way better with layers forced enabled (ro.me runs just fine with but not at all without).

Has someone a bug report from freedesktop.org to link here (I found nothing) ?
(Assignee)

Comment 20

5 years ago
The black areas I'm seeing with Mesa r600 (artifacts that are not due to bug 687831) seem to be caused by GLXLibrary::CreatePixmap using an fbConfig with visual of depth 24 even for CONTENT_COLOR_ALPHA (depth 32) aSurface.

It seems that GLX_BIND_TO_TEXTURE_RGBA_EXT is not sufficient to select an fbConfig with an alpha channel.  We should select a visual compatible with the surface (or pick the visual for the surface from an appropriate fbConfig).

http://www.opengl.org/sdk/docs/man/xhtml/glXCreatePixmap.xml says
"BadMatch is generated if pixmap was not created with a visual
that corresponds to config."
A Pixmaps is not created with a visual, but it is created with a depth.
Assignee: nobody → karlt

Comment 21

5 years ago
Reproducible with Intel HD20000 graphs. Typing is slow, UI is buggy and there's a HUGE memory leak.

This happens regardless of if composting is enabled or not.

And it appears Intel's mesa openGL implementation is ok, considering I see no problems with openGL accelerated QT (including kwin).

Comment 22

5 years ago
Also: Gentoo with mesa 7.11.2

Comment 23

5 years ago
aa... sorry for multiple posting, but on Debian stable with Nvidia 6100 graphics with backported iceweasel, it works fine.
(Assignee)

Comment 24

5 years ago
Created attachment 645674 [details] [diff] [review]
select config in CreatePixmap to match Pixmap format

The GLX_BIND_TO_TEXTURE_RGB_EXT/GLX_TEXTURE_FORMAT_EXT changes are orthogonal to the visual/size changes but related.  They texture format changes aren't necessary on my system (where all fbconfigs support both), but it sounds like the right thing to do, to avoid copies at least.

"The drawable attribute GLX_TEXTURE_FORMAT_EXT determines the base internal
 format of the texture."
"GLX_TEXTURE_FORMAT_EXT describes the texture format this pixmap can be
 bound to."
(Assignee)

Updated

5 years ago
Duplicate of this bug: 778005
(Assignee)

Updated

5 years ago
Blocks: 778013
(Assignee)

Updated

5 years ago
Attachment #645674 - Flags: review?(matt.woodrow)

Comment 26

5 years ago
Reproducible with FF (iceweasel) 10 on Debian testing (now awaiting freeze) with core i3 2120.
Attachment #645674 - Flags: review?(matt.woodrow) → review+
(Assignee)

Comment 27

5 years ago
https://tbpl.mozilla.org/?tree=Try&rev=47e0b459eb76

https://hg.mozilla.org/integration/mozilla-inbound/rev/d0fed2c58607
Flags: in-testsuite-
https://hg.mozilla.org/mozilla-central/rev/d0fed2c58607
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17

Comment 29

5 years ago
I tested under latest nightly, and the black square problem has been solved.
The UI is still causes problem for example when I open the settings dialog, some of buttons, and text sometimes blinking, disappear and come back again. Should I fill a sepereted ticket?
(Assignee)

Updated

5 years ago
No longer blocks: 778013
Duplicate of this bug: 778013
(Assignee)

Comment 31

5 years ago
(In reply to Kami from comment #29)
I don't think this change made it into this most recent nightly:
20120801030520
http://hg.mozilla.org/mozilla-central/rev/582d4c67b3a7

It should be in the next nightly (not available yet), so if you still see issues with that then please file, including the revision from about:buildconfig, and CC me.

Comment 32

5 years ago
I will check
(Reporter)

Comment 33

5 years ago
OK, as I filed that bug, I guess I should test and verify as well. :)

tl;dr: Seems to work nicely now.


My openSUSE Factory now is roughly at the state of soon-to-be-released openSUSE 12.2, with kernel 3.4.4 and X.org 1.12.3, for reference.

Self-built trunk Firefox build:
UA: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0
Built from http://hg.mozilla.org/mozilla-central/rev/2ac77f687a23
(if you don't want to check hg, that's a state from very recently today)

From about:support:
Adapter Description: Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Desktop
Vendor ID: Tungsten Graphics, IncDevice IDMesa DRI Intel(R) Sandybridge Desktop
Driver Version: 3.0 Mesa 8.0.4
WebGL Renderer: Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Desktop  -- 3.0 Mesa 8.0.4
GPU Accelerated Windows: 5/5 OpenGL


With all that, after a few minutes of use, it looks like everything's working and looking correctly. I will keep OpenGL layers enabled and also will do some WebGL testing in the next days, will report new bugs with details if needed.

That said, good work and thanks for figuring this out and fixing it!
Status: RESOLVED → VERIFIED
(Assignee)

Updated

5 years ago
Depends on: 779786

Comment 34

5 years ago
For what it's worth, I recently enabled SNA acceleration on my Ironlake system (using the 2.20 intel driver and the 3.5 kernel). The problem has disappeared EXCEPT when the Firefox "Add On Bar" is hidden. As long as the bar is visible, I get a big performance improvement with no flickering.
(Assignee)

Comment 35

5 years ago
Can you file a new bug, please Ryan, describing the artifacts and when you see them, and attach glxinfo output?

Comment 36

5 years ago
Looks okay to me, thank you for the fix.

Comment 37

5 years ago
My apologies; I should have noted that I was still running the Firefox 14 (just thought the behavior with SNA enable might shed further light into the cause).

Thank you for the fix!
(Assignee)

Updated

5 years ago
Depends on: 780059

Updated

5 years ago
Duplicate of this bug: 669983

Comment 39

4 years ago
Since FF 17 there's been a new bug --

https://bugzilla.mozilla.org/show_bug.cgi?id=818041
You need to log in before you can comment on or make changes to this bug.