Bug 594876 (ogl-linux-beta)

[Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware

REOPENED
Assigned to

Status

()

Core
Graphics
REOPENED
7 years ago
17 days ago

People

(Reporter: jrmuizel, Assigned: acomminos)

Tracking

(Depends on: 21 bugs, Blocks: 10 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [k9o:p?:fx?] [games:p-])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(5 attachments)

Comment hidden (empty)
(Reporter)

Updated

7 years ago
Alias: ogl-linux-beta
(Reporter)

Updated

7 years ago
Depends on: 586463
(Reporter)

Updated

7 years ago
Depends on: 586462
Depends on: 595055

Comment 1

7 years ago
Is this taking ANY priority? Or is it that we'll get the OpenGL version after Firefox 6 gets released 3 years later...

Comment 2

7 years ago
Lots of Linux developers but much fewer Linux users. There are priorities here and plenty of betas left. Besides, this specific bug is bran new; give it at least a little time to have some activity. Please don't whine in tracking bugs.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 3

7 years ago
I'm just worried about when it will be implemented.

+ I've heard that they will be using Xrender also which I've heard only works well for ATI's fglrx...

Updated

7 years ago
Depends on: 580756

Comment 4

7 years ago
Should probably depend on bug 594308 and bug 580410, too?

Updated

7 years ago
Depends on: 594308

Updated

7 years ago
Depends on: 580410

Comment 5

7 years ago
(In reply to comment #4)
Yeah, added. I think they just got lost here when OSX and Linux were split into two different OpenGL tracking bugs.
Summary: [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on linux → [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on Linux

Comment 6

7 years ago
I have an ATI card with OSS driver. Please tell me which nightly build it is worth to start testing. I can't run any test suite but I can test normal browsing.

Comment 7

7 years ago
(In reply to comment #6)
> I can't run any test suite

Actually, yes you can, and easily using an extension:
http://jagriffin.wordpress.com/2010/08/30/introducting-grafx-bot/

Do so and you can send your results to be aggregated and investigated for better hardware support for everyone. :)

Comment 8

7 years ago
Yes, I can do this, thank you for your hint.

Comment 9

7 years ago
Requesting blocking betaN+ or beta7+ if we want feature parity with Mac for OpenGL (bug 580405). Joe Drew?
blocking2.0: --- → ?
I don't think we're going to be in a position to be able to turn OpenGL on by default. I will very happily take all the bugs that make it possible to do so, but I think we're going to end up needing to have an opt-in checkbox. (We might be able to whitelist certain drivers, like the NVIDIA proprietary driver and maybe the free ATI driver, but we've seen a lot of very bad bugs with the current driver situation on Linux, and I don't want to commit to turning OpenGL on by default for that reason.)
blocking2.0: ? → -

Comment 11

7 years ago
Thanks for the info Joe. That's pretty much what I expected, unfortunately.
Depends on: 593874

Comment 12

7 years ago
(In reply to comment #10)
> We might be able to whitelist certain drivers, like the NVIDIA
> proprietary driver and maybe the free ATI driver

Is there a separate bug for this, or do we need to file one? (or is that to be handled in this bug?)

Nice to know that the free ATI driver, which I am currently using, is a possibility... ;)

Comment 13

7 years ago
(rearranging bug title wording so the Linux and Mac tracking bugs don't look exactly the same in bugmail when truncated; don't bury the lead)
Hardware: x86 → All
Summary: [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on Linux → [Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware
Version: unspecified → Trunk

Updated

7 years ago
Depends on: 597141

Updated

7 years ago
Depends on: 602190
No longer depends on: 580410
Depends on: 604047

Comment 14

7 years ago
I get this in my mail - 

          What    |Old Value                   |New Value
----------------------------------------------------------------------------
            Status|UNCONFIRMED                 |RESOLVED
        Resolution|                            |DUPLICATE
Depends on: 648604
Created attachment 533146 [details] [diff] [review]
Turn OpenGL on by default for linux

We also need to make sure this gets disabled in the aurora branch next week, what do I need to do to track that?
Attachment #533146 - Flags: review?
Attachment #533146 - Flags: review? → review?(joe)

Comment 16

6 years ago
I did enabled hardware acceleration, but I got half the FPS to that in chromium.
Assignee: nobody → matt.woodrow+bugzilla
Comment on attachment 533146 [details] [diff] [review]
Turn OpenGL on by default for linux

When you land this, set tracking-firefox6 to ? so we're sure to back this out in Aurora for fx6.
Attachment #533146 - Flags: review?(joe) → review+
Landed as http://hg.mozilla.org/mozilla-central/rev/f9a070327df8 and then backed out because of Mochitest failures http://hg.mozilla.org/mozilla-central/rev/5373d5d7e0f1
Depends on: 658921
Matt, was this orange on try?
Not when I last tried it, but it may have been when texture_from_pixmap was broken.
Depends on: 659560
Created attachment 549254 [details] [diff] [review]
Turn OpenGL on by default for linux v2

Rebased and fixed the mochitest for this change.

Carrying forward r=joe
Attachment #549254 - Flags: review+
Depends on: 675474
Depends on: 671259
Depends on: 655017
Depends on: 675073
Depends on: 678134
Depends on: 678372
Depends on: 659932
Looking good on tryserver, trying this again!

http://hg.mozilla.org/integration/mozilla-inbound/rev/0a920411e64c

Fingers (and toes) crossed.
Whiteboard: [inbound]
I believe one of the changesets in that push (bug 594876, bug 675474 or bug 675532) has caused an OSX 10.6 reftest perma-orange, so needs backing out:
http://tbpl.allizom.org/?tree=Mozilla-Inbound&usebuildbot=1&rev=0a920411e64c
Backed out on inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7797172fc164
http://hg.mozilla.org/integration/mozilla-inbound/rev/955f83dc4372
Whiteboard: [inbound]
Depends on: 680817
Note that Talos reported massive perf regressions on Linux for the push this was part.
... for the push this was part of.

I see that Matt filed bug 680817 on this.

Updated

6 years ago
Depends on: 678940
Blocks: 692975

Updated

6 years ago
Depends on: 694258

Updated

6 years ago
Depends on: 630346

Updated

6 years ago
Depends on: 606649

Updated

6 years ago
Depends on: 630620

Updated

6 years ago
No longer depends on: 694258

Updated

6 years ago
Depends on: 693149
No longer depends on: 693149
Depends on: 687831

Updated

6 years ago
Blocks: 707722

Updated

6 years ago
No longer blocks: 707722
Depends on: 707722
Depends on: 709510
Depends on: 702158

Updated

5 years ago
Blocks: 749721

Updated

5 years ago
Whiteboard: [k9o:p?:fx?] [games:p2]
Depends on: 722012
Depends on: 777170
Depends on: 778029

Updated

5 years ago
Depends on: 783043
Depends on: 787853
Depends on: 788319
I just pushed to try with the pref layers.acceleration.force-enabled = true to get an idea of the current situation on Linux:

https://tbpl.mozilla.org/?tree=Try&rev=673649ad7d36

I did not disable xrender. It may be worth trying also with gfx.xrender.enabled = false if this does not show good results.
(In reply to Nicolas Silva [:nical] from comment #27)
> I just pushed to try with the pref layers.acceleration.force-enabled = true
> to get an idea of the current situation on Linux:

You can see a recent try build here: https://bugzilla.mozilla.org/show_bug.cgi?id=787853#c10

Comment 29

5 years ago
Adapter DescriptionATI Technologies Inc. -- AMD Radeon HD 6900 Series 
Vendor IDATI Technologies Inc.
Device IDAMD Radeon HD 6900 Series 
Driver Version4.2.11762 Compatibility Profile ContextWebGL RendererATI Technologies Inc. -- AMD Radeon HD 6900 Series  -- 4.2.11762 Compatibility Profile Context
GPU Accelerated Windows1/1 OpenGL

with xrender set to false even the current aurora seems to work. Not quite sure how i tell if its working though - about:support seems to indicate it is. performance isnt much different. 

there are a few transient image artifacts but otherwise it seems ok.
(In reply to paulf from comment #29)
> with xrender set to false even the current aurora seems to work.

And what with xrender enabled?

> there are a few transient image artifacts but otherwise it seems ok.

If you can reproduce these artifacts on a particular page, please file a new bug blocking this one.

Comment 31

5 years ago
(On my radeon OSS driver with forced layers acceleration the rendering is steadily improving with each Firefox nightly for the last year. Where there was flickering and rendering artifacts all over the page, I can see no problems today. I just don't see any perf advantage, but it works. Even WebGL works. Good work guys!)

Comment 32

5 years ago
With xrender enabled there are the usual ati fglrx bugs. i have one open for that.

the artifacts are transient. 
1 - sometimes the color scheme is messed up in gmail. currently its perfect.
2 - sometimes the background flickers moving images in blogger when composing a post. 

as im not actually sure if the opengl layers are working at all i didnt want to be raising bugs against it.

i can do some retesting if need be - but i would like to know if layers are working as intended or at all or if there are still components missing from the gfx stack ?
(In reply to paulf from comment #29)
> GPU Accelerated Windows1/1 OpenGL

This means 1 out of 1 windows is using GL layers.  i.e. OpenGL is used to composite the layers, as intended.

Probably the most noticeable improvement in performance at this stage would be with high frame-rate WebGL such as
https://developer.mozilla.org/en-US/demos/detail/bananabread

Scaled webm/ogg video should also use less CPU.
http://videos.mozilla.org/serv/marketing/sfx_edutoolkit/asa_historymozilla.ogv

Also expect improvements scrolling LCD antialiased text over fixed backgrounds, but
bug 777170 means that is not yet working as intended.
Depends on: 797568

Comment 34

5 years ago
FYI, with Intel SandyBridge and quite recent kernels and X.org versions, GL layers have been working fine in Nightly for all cases I saw recently - I had the bounding boxes of doorhangers not being transparent for a while (with my custom theme, but without GL layers it was fine), but that has been fixed very recently as well.
As this machine is really fast overall, I can't speak for performance. On hardware and systems like this, I'd feel good with having this turned on by default in Nightly in the near future to get more feedback. Good work, guys! :)

Comment 35

5 years ago
Very stable on Sandybridge now. The previously observed slowdowns or graphical anomalies are gone.

Linux 3.6
Xorg 1.13.99
Mesa 9.1-devel
Intel DDX git
Nouveau DDX git
Depends on: 693149

Updated

5 years ago
Depends on: 807941
Depends on: 819846
Duplicate of this bug: 828799

Comment 37

4 years ago
Seems to work pretty well on ivybridge too:

ubuntu 12.10
kernel 3.5
mesa 9.0
intel 2.20.9

No more artifacts in the interface and scrolling like there used to be, seems to be quite usable. I'll have to give it more testing though.

Comment 38

4 years ago
ivy bridge has a small problem.

In the google search suggestions, sometimes it's going to show a blank list (with the lists's black border but no entries in it).

Also, what about benchmarking? It should be at par to other platforms.

Comment 39

4 years ago
I ran a few benchmarks on the ie10 testdrive site and some of them are still significantly slower than xrender. The most obvious example was psychedelic browsing. 7k+ with just xrender, and around 300 with layers enabled.

Comment 40

4 years ago
(In reply to Brandon Watkins from comment #39)
> I ran a few benchmarks on the ie10 testdrive site and some of them are still
> significantly slower than xrender. The most obvious example was psychedelic
> browsing. 7k+ with just xrender, and around 300 with layers enabled.

What hardware?

Comment 41

4 years ago
ivybridge i5-3210m 2.53ghz, 8gb ram on ubuntu 12.10

Comment 42

4 years ago
With xrender disabled, https://webglsamples.googlecode.com/hg/aquarium/aquarium.html is marginally faster; but it should be a lot faster.

Comment 43

4 years ago
Maybe that could be usefull in the future : GLX_MESA_query_renderer should soon be in Mesa thnaks to Ian Romanick [1]

"The glXQueryRendererIntegerMESA and glXQueryRendererStringMESA functions allow applications query a bunch of aspects about the driver and hardware before creating a context:

    Driver version
    Driver vendor
    Hardware vendor (may be different from driver vendor!)
    Hardware chipset (PCI ID)
    Available memory
    UMA vs. non-UMA
    Supported and prefered (by the driver) GL profiles"


[1] http://www.paranormal-entertainment.com/idr/blog/posts/2013-03-01T23:15:18Z-GLX_MESA_query_renderer_out_for_review/

Updated

4 years ago
Depends on: 825944

Updated

4 years ago
Depends on: 864628
Whiteboard: [k9o:p?:fx?] [games:p2] → [k9o:p?:fx?] [games:p-]

Comment 44

4 years ago
I am having this problem too. My notebook is good, but the WebGL graphics is very slow. I am using Ubuntu 13.04, 64 bits, Firefox updated with last version.
Duplicate of this bug: 751082
Blocks: 1010527
Duplicate of this bug: 1060406

Comment 47

3 years ago
Coming from bug 1060406, this issue causes a huge CPU consumption when playing some videos on my hardware (Intel graphics cards on Linux : one Ivy bridge and one Atom).
Some VP8 or VP9 videos are playing fine on Totem but don't play at all on Firefox because of lack of CPU power.

I read the workarounds above of setting layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but they did not work for me : the about:support page always says 0 accelerated windows and the CPU consumption remains the same.

Is there any way to manually enable accelerated windows on Intel graphics cards on Linux?
NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same behavior with Firefox 31 downloaded from Mozilla
(In reply to Mossroy from comment #47)
> Coming from bug 1060406, this issue causes a huge CPU consumption when
> playing some videos on my hardware (Intel graphics cards on Linux : one Ivy
> bridge and one Atom).
> Some VP8 or VP9 videos are playing fine on Totem but don't play at all on
> Firefox because of lack of CPU power.
> 
> I read the workarounds above of setting
> layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but
> they did not work for me : the about:support page always says 0 accelerated
> windows and the CPU consumption remains the same.
> 
> Is there any way to manually enable accelerated windows on Intel graphics
> cards on Linux?
> NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same
> behavior with Firefox 31 downloaded from Mozilla

Video acceleration using GStreamer would be bug 894372.

Comment 49

3 years ago
Thanks Marco, but I don't think we're talking about the same thing.
If I understood correctly, the bug 894372 you mention is about activating hardware decoding through GStreamer+VAAPI.
The tests I made were with VP8 and VP9 video codecs, which are not decoded by Gstreamer as far as I know. And, in any case, my hardware does not support hardware VP8/VP9 decoding.

Based on the comments in bug 1060406, it seems that the CPU overhead I face would be due to Firefox window composition. It seems to depend on the hardware : some people with OpenGL accelerated windows do not have this overhead. I believe this is why it has been marked as duplicate of this issue.

I'd like to check these assumptions by manually enabling accelerated windows in Firefox (if it's possible)
(In reply to Mossroy from comment #49)
> Thanks Marco, but I don't think we're talking about the same thing.
> If I understood correctly, the bug 894372 you mention is about activating
> hardware decoding through GStreamer+VAAPI.
> The tests I made were with VP8 and VP9 video codecs, which are not decoded
> by Gstreamer as far as I know. And, in any case, my hardware does not
> support hardware VP8/VP9 decoding.
> 
> Based on the comments in bug 1060406, it seems that the CPU overhead I face
> would be due to Firefox window composition. It seems to depend on the
> hardware : some people with OpenGL accelerated windows do not have this
> overhead. I believe this is why it has been marked as duplicate of this
> issue.
> 
> I'd like to check these assumptions by manually enabling accelerated windows
> in Firefox (if it's possible)

layers.acceleration.force-enabled and a restart of the browser should be all that's required to trigger OpenGL+OMTC, though there may be blacklisted drivers now.

For basic (non-opengl) OMTC you can enable layers.offmainthreadcomposition.enabled with acceleration disabled

Comment 51

3 years ago
Thanks John.
I tested layers.offmainthreadcomposition.enabled (with acceleration disabled). It had no significant effect on my computers.
So I suppose the Intel open-source drivers I use on these computers are blacklisted?

How could I check that?
If someone could point me to where this blacklist is (in the source code, I suppose), I might try to remove it and recompile?
On linux, unless you are using firefox nightly, you also need to set either of these two environment variables:
export MOZ_USE_OMTC=1
export MOZ_OMTC_ENABLED=1
in addition to the prefs. There are historical reasons to that but in short, need to initialize X in thread-safe mode before the service that can read prefs is created (so at a point where we can only use environment variables). We didn't want to initialize X in thread-safe mode unless OMTC is activated because it adds a bit of overhead.
The plan is to enable OMTC on linux for everyone asap, but we are getting delayed by some fire fighting on windows at the moment, but soon-ish this should become easier.

Comment 53

3 years ago
Thanks Nicolas.
With these environment variables set and layers.acceleration.force-enabled=true, I manage to have an accelerated window in about:support : "1/1 OpenGL (OMTC)"

Unfortunately, it does not seem to make a visible difference when playing my test WebM videos : the CPU consumption is still ~ twice more than with Totem, and the video is still choppy on the netbook (while smooth in Totem)

Can I test anything else?

Comment 54

3 years ago
(In reply to Mossroy from comment #53)
> Thanks Nicolas.
> With these environment variables set and
> layers.acceleration.force-enabled=true, I manage to have an accelerated
> window in about:support : "1/1 OpenGL (OMTC)"
> 
> Unfortunately, it does not seem to make a visible difference when playing my
> test WebM videos : the CPU consumption is still ~ twice more than with
> Totem, and the video is still choppy on the netbook (while smooth in Totem)
> 
> Can I test anything else?

Maybe your local installation or the recent entanglement of layers.acceleration.force-enabled and OMTC is the problem.
You could try an older live system like Ubuntu 13.10 64-bit (including Firefox 24 without OMTC):

Download Ubuntu 13.10 64-bit from

http://releases.ubuntu.com/13.10/

burn it, boot it, select "Try Ubuntu" (not install), set layers.acceleration.force-enabled to true, restart Firefox and see if the CPU usage of your WebM video gets reduced.

Comment 55

3 years ago
Thanks a lot Cresto, you were right!

With Firefox 24 (from Ubuntu 13.10), setting layers.acceleration.force-enabled to true is enough to get hardware accelerated window in about:support : "1/1 OpenGL"
It's still OK with Firefox 26 (from Mozilla), but fails since Firefox 27 (from Mozilla : "0/1 Basic")
SO I suppose the regression has been introduced in Firefox 27.

The CPU usage is indeed reduced with OpenGL acceleration.
Here are the approximate CPU consumptions I have with a WebM video (VP8+Vorbis) played on an old netbook (Atom dual core N570 @1.66GHz with HT)
Firefox 26 : 90% + 16% compiz + 16% xorg + 8% pulseaudio (total = 130%)
Firefox 27 (or Firefox 26 without layers.acceleration.force-enabled to true) : 110% + 30% compiz + 13% xorg + 8% pulseaudio (total = 161%)
By comparison :
Totem : 65% + 13% compiz + 13% xorg + 5% pulseaudio (total = 96%)
Chromium 34 : 135% (3 processes : 90+25+20) + 18% compiz + 13% xorg + 18% pulseaudio (total = 184%)

To sum up, there is still an overhead when compared with Totem, but having OpenGL accelerated windows is really worth it, as it reduces this overhead in a noticeable way.

I hope the following versions of Firefox will fix these issues : at least allow to force-enable OpenGL, and at best enable it by default
NB : I tested with Firefox nightly (36.0a1) in the same conditions. The about:support says "1/1 OpenGL (OMTC)", and the CPU consumption is : 135% + 20% compiz + 20% xorg + 5% pulseaudio (total = 180%. Not sure this test is relevant because it seems that Firefox nightly eats ~35% CPU, even when idle)

Updated

3 years ago
Depends on: 1093060
Blocks: 1152974

Updated

2 years ago
Depends on: 1113647

Updated

2 years ago
Depends on: 1177091

Updated

2 years ago
Depends on: 1177079

Updated

2 years ago
Depends on: 801286

Updated

2 years ago
Depends on: 1135499

Updated

2 years ago
Depends on: 1181545
Depends on: 1184534
No longer depends on: 1181545
Depends on: 1187440
Assignee: matt.woodrow → acomminos
Depends on: 1189132

Updated

2 years ago
Depends on: 1181545
Depends on: 1193615
Depends on: 1198869

Updated

2 years ago
Depends on: 1194644

Comment 56

2 years ago
Is there any progress on this one?
At leats with the open-source drivers (radeon, intel), Firefox works well with opengl acceleration turned on.
(In reply to Clemens Eisserer from comment #56)
> Is there any progress on this one?
> At leats with the open-source drivers (radeon, intel), Firefox works well
> with opengl acceleration turned on.

At the moment it's best to wait for the transition gtk2->gtk3 to be done and stable before we ship another change that greatly impact the graphics pipeline on linux. We also need to figure out whether the servers we run tests on have have a reliable graphics stack and have them run tests with opengl compositing in addition to the software compositing configuration, and figure out the remaining issues (there are open bugs about gl compositing on linux, I don't think that it is free of regressions at the moments, even if it mostly works well). There are also other things to do on linux like moving away from cairo's xrender backend, that have an impact on the compositing backend so we have to figure out what the dependencies are there.
(In reply to Clemens Eisserer from comment #56)
> Is there any progress on this one?

My last post sounded perhaps a bit pessimistic, but to answer your question more directly, :acomminos has made some progress on this front, lately.

Updated

2 years ago
Depends on: 1193642
Blocks: 1210726

Comment 59

2 years ago
(In reply to Nicolas Silva [:nical] from comment #57)
> At the moment it's best to wait for the transition gtk2->gtk3 to be done and
> stable before we ship another change that greatly impact the graphics
> pipeline on linux.

But GTK+ 3 already is enabled by default now:

https://bugzilla.mozilla.org/show_bug.cgi?id=1186003

?

(In reply to Nicolas Silva [:nical] from comment #57)
> There are also other things to do on
> linux like moving away from cairo's xrender backend, that have an impact on
> the compositing backend so we have to figure out what the dependencies are
> there.

Do you have a link?

Regards
(In reply to nw9165-3201 from comment #59)
> But GTK+ 3 already is enabled by default now:

It hasn't made it to the release channel yet. Regressions from these kind of changes usually show up only when the new feature hits a large population of users, so waiting a bit between risky changes helps with being able to react quickly when bugs show up in the beta or release channels (and more importantly not having too many of these late bugs at the same time to deal with). Gtk3 isn't in a worrying state as far as I know so we should be good soon.

> (In reply to Nicolas Silva [:nical] from comment #57)
> Do you have a link?

Bug 1180942
Depends on: 1234058
Depends on: 1193855
Depends on: 1241874

Updated

a year ago
Blocks: 1260559
Depends on: 1263678
Depends on: 1267137
Blocks: 1274686
Depends on: 1279335
Created attachment 8763262 [details]
Bug 594876 - Fuzz reftests with noise from enabling layers acceleration on Linux.

Review commit: https://reviewboard.mozilla.org/r/59522/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59522/
Attachment #8763262 - Flags: review?(nical.bugzilla)
Attachment #8763263 - Flags: review?(nical.bugzilla)
Attachment #8763264 - Flags: review?(nical.bugzilla)
Created attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

Review commit: https://reviewboard.mozilla.org/r/59524/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59524/
Created attachment 8763264 [details]
Bug 594876 - Accelerate layers by default for nightlies on Linux.

Review commit: https://reviewboard.mozilla.org/r/59526/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59526/
It seems like a good time now to enable this on Nightly; these patches enable layers acceleration by default on GTK.

Let's triage, start making use of the downloadable blocklist, and improve glxtest as we start getting data in from nightly users.

Comment 65

11 months ago
Comment on attachment 8763264 [details]
Bug 594876 - Accelerate layers by default for nightlies on Linux.

https://reviewboard.mozilla.org/r/59526/#review56620
Attachment #8763264 - Flags: review?(nical.bugzilla) → review+

Comment 66

11 months ago
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review56622
Attachment #8763263 - Flags: review?(nical.bugzilla) → review+

Updated

11 months ago
Attachment #8763262 - Flags: review?(nical.bugzilla) → review+

Comment 67

11 months ago
Comment on attachment 8763262 [details]
Bug 594876 - Fuzz reftests with noise from enabling layers acceleration on Linux.

https://reviewboard.mozilla.org/r/59522/#review56624

\o/

Comment 68

11 months ago
Pushed by acomminos@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5bde2c12831c
Enable layers acceleration by default on Linux. r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/d8b83ff870a3
Test that acceleration is used on Linux. r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/cafa7213ef23
Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical
Backed out for failing reftest preserves3d-nested.html at least on Linux:

https://hg.mozilla.org/integration/mozilla-inbound/rev/c583dc0f3f4a2fd3e0d4b478a599c1f613085d52
https://hg.mozilla.org/integration/mozilla-inbound/rev/a79452abaf55f1cfb37f943924e02e54e1d23c4a
https://hg.mozilla.org/integration/mozilla-inbound/rev/3ce999f6a0ef50904d7d7ebf8463ba2c70ef8028

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=cafa7213ef23c20fd5774db249db63b07314dcd9
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=30271778&repo=mozilla-inbound
Flags: needinfo?(andrew)
Sorry, reftest fuzz order was incorrect for that test. Will fix and reland when I get back.
Flags: needinfo?(andrew)
Be aware that the push had many timeouts in various mochitests. Please push to Try if it isn't obvious that the changes fill fix these.
Depends on: 1280744

Updated

11 months ago
Depends on: 1277981
No longer depends on: 1277981

Updated

11 months ago
Depends on: 1285507
Depends on: 1292326
Depends on: 1294232
Depends on: 1296086
Blocks: 1280771
With larger AWS instances, the software GL infrastructure in bug 1296086 landing, and better Linux blocklisting, we have a better chance at making this stick. Let's make it exclusive to nightly builds for now, and see how things go.
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Due to bug 1296086, test_acceleration.html has been flagged TODO (as we only accelerate on TaskCluster tests).

Thanks!
Attachment #8763263 - Flags: review+ → review?(nical.bugzilla)
(Assignee)

Comment 79

9 months ago
mozreview-review
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70500
Attachment #8763263 - Flags: review?(andrew)
(Assignee)

Comment 80

9 months ago
mozreview-review
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70502
Attachment #8763263 - Flags: review?(andrew)

Comment 81

9 months ago
mozreview-review
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70618
Attachment #8763263 - Flags: review?(nical.bugzilla) → review+

Comment 82

9 months ago
Pushed by acomminos@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/314eb9761599
Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical
https://hg.mozilla.org/integration/autoland/rev/f35636ae9fdb
Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. r=nical
https://hg.mozilla.org/integration/autoland/rev/32fd2e8a3be8
Accelerate layers by default for nightlies on Linux. r=nical
Depends on: 1296733
https://hg.mozilla.org/mozilla-central/rev/314eb9761599
https://hg.mozilla.org/mozilla-central/rev/f35636ae9fdb
https://hg.mozilla.org/mozilla-central/rev/32fd2e8a3be8
Status: NEW → RESOLVED
Last Resolved: 9 months ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51

Comment 84

9 months ago
Thank you!

Updated

9 months ago
See Also: → bug 1296911

Updated

9 months ago
Depends on: 1297004

Updated

9 months ago
See Also: → bug 1278957

Updated

9 months ago
Depends on: 1297809
Depends on: 1298333

Comment 85

9 months ago
I have before the layers accelerated, the only thing I have noticed is the noise on the browser, apart with my hd 4600 intel hd and arch linux all is going well

Updated

9 months ago
Depends on: 1298692

Comment 86

9 months ago
I think I was bitten by the fix for this ticket.  Details here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1299588
Depends on: 1299588
Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest Nightlies (since the fix) fail to start on the machine. 
Using the following 2 prefs "layers.acceleration.force-enabled:false" and "layers.acceleration.disabled:true" makes the issue go away.

Ubuntu 14.04 x64 works as expected.
(In reply to Ciprian Muresan [:cmuresan] from comment #87)
> Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest
> Nightlies (since the fix) fail to start on the machine. 
> Using the following 2 prefs "layers.acceleration.force-enabled:false" and
> "layers.acceleration.disabled:true" makes the issue go away.
> 
> Ubuntu 14.04 x64 works as expected.

This is probably the same issue that mirh pointed out in bug 1298333 comment 6.
(In reply to Marco Castelluccio [:marco] from comment #88)
> This is probably the same issue that mirh pointed out in bug 1298333 comment
> 6.

It seems so, thanks for pointing that out.
(In reply to Ciprian Muresan [:cmuresan] from comment #89)
> (In reply to Marco Castelluccio [:marco] from comment #88)
> > This is probably the same issue that mirh pointed out in bug 1298333 comment
> > 6.
> 
> It seems so, thanks for pointing that out.

Do you have the same gfx card and same driver version? If you don't, perhaps
you can add a comment in that bug saying what yours are.

Updated

8 months ago
Depends on: 1299860
Depends on: 1304347
Depends on: 1304195
Depends on: 1297212
Blocks: 1302974

Updated

8 months ago
Depends on: 1302850
Blocks: 816451

Comment 91

7 months ago
Would it make sense to add bug 1306912 to the "depends on" list?
Blocks: 1307158
(In reply to Clemens Eisserer from comment #91)
> Would it make sense to add bug 1306912 to the "depends on" list?

Yes, done.
Depends on: 1306912

Comment 93

7 months ago
and another one please: 1306974
I only see this issue when OpenGL is enabled, and haven't experienced it with earlier versions (48/49(?)) - so either a firefox or mesa regression.

Updated

7 months ago
Depends on: 1306974

Updated

7 months ago
Depends on: 1305675

Updated

6 months ago
Depends on: 1320340
Lee, please reopen this once you fix bug 1323284, turning acceleration off by default.
Flags: needinfo?(lsalzman)
Depends on: 1297450
As part of bug 1323284, we disabled acceleration again until we have time/resources to better investigate this. Reopening...
Status: RESOLVED → REOPENED
Flags: needinfo?(lsalzman)
Resolution: FIXED → ---

Updated

5 months ago
See Also: → bug 1323991
blocking2.0: - → ---
status-firefox51: fixed → ---
Target Milestone: mozilla51 → ---

Updated

5 months ago
Depends on: 1261832

Comment 96

a month ago
I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on Linux Debian (i686/32bits). Disabling hardware acceleration had no effect.
(In reply to Etienne Robillard from comment #96)
> I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on
> Linux Debian (i686/32bits). Disabling hardware acceleration had no effect.

You can try toggling the gfx.xrender.enabled pref and see if it helps either way.

Comment 98

a month ago
(In reply to Lee Salzman [:lsalzman] from comment #97)
> You can try toggling the gfx.xrender.enabled pref and see if it helps either
> way.

I tried disabling gfx.xrender.enabled without any effects. Furthermore, I don't understand the logic
of disabling XRender for local X11 connections.

Comment 99

a month ago
Not sure the meta bug is the right one to discuss that...
Also not sure why (in such a.. _complex and longstanding_ issue) reporting issues with a 1 year and half old codebase would really help anything when all the developments happens on builds with a 10 higher number.
You need to log in before you can comment on or make changes to this bug.