Closed Bug 707722 Opened 13 years ago Closed 12 years ago

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

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla17

People

(Reporter: kairo, Assigned: karlt)

References

Details

Attachments

(3 files)

Screenshot 1: Scrolling
285.40 KB, image/png
Details
Screenshot 2: Bringing work space into view
272.56 KB, image/png
Details
select config in CreatePixmap to match Pixmap format
4.04 KB, patch
mattwoodrow
: review+
Details | Diff | Splinter Review 
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
Attached image 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.
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.
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.
Blocks: ogl-linux-beta
No longer depends on: ogl-linux-beta
(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.
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.
For me there is no flickering, but same problem with scrolling (like on attached "Screenshot 1: Scrolling") on R600g and Mesa 8.0.1.
(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?
(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.
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.
I should have mentioned that like runetmember, I only experience the flickering, no artifacts.
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...
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.
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.
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.
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) ?
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
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).
Also: Gentoo with mesa 7.11.2
aa... sorry for multiple posting, but on Debian stable with Nvidia 6100 graphics with backported iceweasel, it works fine.
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."
Blocks: 778013
Attachment #645674 - Flags: review?(matt.woodrow)
Reproducible with FF (iceweasel) 10 on Debian testing (now awaiting freeze) with core i3 2120.
Attachment #645674 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/d0fed2c58607
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
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?
No longer blocks: 778013
(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.
I will check
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
Depends on: 779786
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.
Can you file a new bug, please Ryan, describing the artifacts and when you see them, and attach glxinfo output?
Looks okay to me, thank you for the fix.
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!
Depends on: 780059
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.

Attachment

General

Creator:
Created:
Updated:
Size: