Last Comment Bug 594876 - (ogl-linux-beta) [Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware
(ogl-linux-beta)
: [Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at le...
Status: REOPENED
[k9o:p?:fx?] [games:p-]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Linux
-- normal with 45 votes (vote)
: ---
Assigned To: Andrew Comminos [:acomminos] (back to classes, will be slow)
:
: Milan Sreckovic [:milan]
Mentors:
: 828799 1060406 (view as bug list)
Depends on: 777170 788319 801286 1113647 1135499 1181545 1193642 1193855 1194644 1241874 1261832 1294232 1296086 1296733 1297212 1297809 1298692 1302850 1305675 1306912 1320340 580756 586462 586463 593874 594308 595055 597141 602190 604047 606649 630346 630620 648604 655017 658921 659560 659932 671259 675073 675474 678134 678372 678940 680817 687831 693149 702158 707722 709510 722012 778029 783043 787853 797568 807941 819846 825944 864628 1093060 1177079 1177091 1184534 1187440 1189132 1193615 1198869 1234058 1263678 1267137 1279335 1280744 1285507 1292326 1297004 1297450 1298333 1299588 1299860 1304195 1304347 1306974
Blocks: 692975 k9o-Hardware-Accel 816451 slow-linux-webgl 1152974 1210726 1274686 1280771 1302974 1307158 1260559
  Show dependency treegraph
 
Reported: 2010-09-09 11:39 PDT by Jeff Muizelaar [:jrmuizel]
Modified: 2017-02-26 03:30 PST (History)
93 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

MozReview Requests
Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:
Show discarded requests

Attachments
Turn OpenGL on by default for linux (1.07 KB, patch)
2011-05-17 19:12 PDT, Matt Woodrow (:mattwoodrow)
joe: review+
Details | Diff | Splinter Review
Turn OpenGL on by default for linux v2 (1.85 KB, patch)
2011-07-28 15:48 PDT, Matt Woodrow (:mattwoodrow)
matt.woodrow: review+
Details | Diff | Splinter Review
Bug 594876 - Fuzz reftests with noise from enabling layers acceleration on Linux. (58 bytes, text/x-review-board-request)
2016-06-17 09:34 PDT, Andrew Comminos [:acomminos] (back to classes, will be slow)
nical.bugzilla: review+
Details | Review
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. (58 bytes, text/x-review-board-request)
2016-06-17 09:34 PDT, Andrew Comminos [:acomminos] (back to classes, will be slow)
nical.bugzilla: review+
Details | Review
Bug 594876 - Accelerate layers by default for nightlies on Linux. (58 bytes, text/x-review-board-request)
2016-06-17 09:34 PDT, Andrew Comminos [:acomminos] (back to classes, will be slow)
nical.bugzilla: review+
Details | Review

Description User image Jeff Muizelaar [:jrmuizel] 2010-09-09 11:39:50 PDT

    
Comment 1 User image dE 2010-09-11 22:39:49 PDT
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 User image Dave Garrett 2010-09-12 06:36:50 PDT
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 User image dE 2010-09-12 23:33:07 PDT
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...
Comment 4 User image Mikko Rantalainen 2010-09-17 06:57:21 PDT
Should probably depend on bug 594308 and bug 580410, too?
Comment 5 User image Dave Garrett 2010-09-17 07:33:55 PDT
(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.
Comment 6 User image :aceman 2010-09-18 18:11:53 PDT
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 User image Dave Garrett 2010-09-18 20:04:12 PDT
(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 User image :aceman 2010-09-19 08:06:19 PDT
Yes, I can do this, thank you for your hint.
Comment 9 User image Dave Garrett 2010-09-21 09:28:47 PDT
Requesting blocking betaN+ or beta7+ if we want feature parity with Mac for OpenGL (bug 580405). Joe Drew?
Comment 10 User image Joe Drew (not getting mail) 2010-09-21 09:42:07 PDT
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.)
Comment 11 User image Dave Garrett 2010-09-21 09:43:52 PDT
Thanks for the info Joe. That's pretty much what I expected, unfortunately.
Comment 12 User image Dave Garrett 2010-09-21 20:17:39 PDT
(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 User image Dave Garrett 2010-09-21 20:32:09 PDT
(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)
Comment 14 User image dE 2010-10-15 02:06:40 PDT
I get this in my mail - 

          What    |Old Value                   |New Value
----------------------------------------------------------------------------
            Status|UNCONFIRMED                 |RESOLVED
        Resolution|                            |DUPLICATE
Comment 15 User image Matt Woodrow (:mattwoodrow) 2011-05-17 19:12:01 PDT
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?
Comment 16 User image dE 2011-05-17 20:13:59 PDT
I did enabled hardware acceleration, but I got half the FPS to that in chromium.
Comment 17 User image Joe Drew (not getting mail) 2011-05-18 08:01:55 PDT
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.
Comment 18 User image Matt Woodrow (:mattwoodrow) 2011-05-22 17:24:29 PDT
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
Comment 19 User image Joe Drew (not getting mail) 2011-05-22 19:24:44 PDT
Matt, was this orange on try?
Comment 20 User image Matt Woodrow (:mattwoodrow) 2011-05-22 19:35:04 PDT
Not when I last tried it, but it may have been when texture_from_pixmap was broken.
Comment 21 User image Matt Woodrow (:mattwoodrow) 2011-07-28 15:48:41 PDT
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
Comment 22 User image Matt Woodrow (:mattwoodrow) 2011-08-19 19:07:18 PDT
Looking good on tryserver, trying this again!

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

Fingers (and toes) crossed.
Comment 23 User image Ed Morley [:emorley] 2011-08-20 05:54:50 PDT
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
Comment 25 User image Dão Gottwald [:dao] 2011-08-22 05:42:03 PDT
Note that Talos reported massive perf regressions on Linux for the push this was part.
Comment 26 User image Dão Gottwald [:dao] 2011-08-22 05:48:05 PDT
... for the push this was part of.

I see that Matt filed bug 680817 on this.
Comment 27 User image Nicolas Silva [:nical] 2012-09-27 11:28:13 PDT
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.
Comment 28 User image Marco Castelluccio [:marco] 2012-09-27 11:33:12 PDT
(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 User image paulf 2012-09-28 04:21:28 PDT
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.
Comment 30 User image Marco Castelluccio [:marco] 2012-09-28 05:50:55 PDT
(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 User image :aceman 2012-09-28 06:36:30 PDT
(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 User image paulf 2012-09-28 06:59:58 PDT
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 ?
Comment 33 User image Karl Tomlinson (:karlt) 2012-09-28 13:27:24 PDT
(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.
Comment 34 User image Robert Kaiser 2012-10-06 07:23:58 PDT
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 User image Eric Appleman 2012-10-10 13:35:25 PDT
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
Comment 36 User image Joe Drew (not getting mail) 2013-01-10 08:55:26 PST
*** Bug 828799 has been marked as a duplicate of this bug. ***
Comment 37 User image Brandon Watkins 2013-01-30 11:51:00 PST
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 User image dE 2013-02-03 01:22:41 PST
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 User image Brandon Watkins 2013-02-03 07:05:15 PST
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 User image dE 2013-02-03 10:22:42 PST
(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 User image Brandon Watkins 2013-02-03 10:24:56 PST
ivybridge i5-3210m 2.53ghz, 8gb ram on ubuntu 12.10
Comment 42 User image dE 2013-02-06 10:38:05 PST
With xrender disabled, https://webglsamples.googlecode.com/hg/aquarium/aquarium.html is marginally faster; but it should be a lot faster.
Comment 43 User image antistress 2013-03-02 05:16:02 PST
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/
Comment 44 User image u452416 2013-06-05 21:46:31 PDT
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.
Comment 45 User image Jeff Gilbert [:jgilbert] 2013-09-10 08:09:12 PDT
*** Bug 751082 has been marked as a duplicate of this bug. ***
Comment 46 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2014-10-21 18:23:11 PDT
*** Bug 1060406 has been marked as a duplicate of this bug. ***
Comment 47 User image Mossroy 2014-10-25 01:57:18 PDT
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
Comment 48 User image Marco Castelluccio [:marco] 2014-10-25 02:21:11 PDT
(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 User image Mossroy 2014-10-25 02:46:05 PDT
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)
Comment 50 User image John Schoenick [:johns] 2014-10-28 21:52:14 PDT
(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 User image Mossroy 2014-10-29 02:04:51 PDT
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?
Comment 52 User image Nicolas Silva [:nical] 2014-10-29 06:44:46 PDT
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 User image Mossroy 2014-11-01 13:05:22 PDT
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 User image Cresto 2014-11-02 01:50:19 PDT
(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 User image Mossroy 2014-11-02 06:13:34 PST
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)
Comment 56 User image Clemens Eisserer 2015-09-24 08:10:22 PDT
Is there any progress on this one?
At leats with the open-source drivers (radeon, intel), Firefox works well with opengl acceleration turned on.
Comment 57 User image Nicolas Silva [:nical] 2015-09-24 08:25:28 PDT
(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.
Comment 58 User image Nicolas Silva [:nical] 2015-09-24 08:27:50 PDT
(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.
Comment 59 User image N. W. 2015-10-18 11:37:09 PDT
(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
Comment 60 User image Nicolas Silva [:nical] 2015-10-19 01:57:57 PDT
(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
Comment 61 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-17 09:34:30 PDT
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/
Comment 62 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-17 09:34:30 PDT
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/
Comment 63 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-17 09:34:30 PDT
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/
Comment 64 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-17 09:37:35 PDT
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 User image Nicolas Silva [:nical] 2016-06-17 09:39:13 PDT
Comment on attachment 8763264 [details]
Bug 594876 - Accelerate layers by default for nightlies on Linux.

https://reviewboard.mozilla.org/r/59526/#review56620
Comment 66 User image Nicolas Silva [:nical] 2016-06-17 09:40:55 PDT
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
Comment 67 User image Nicolas Silva [:nical] 2016-06-17 09:41:43 PDT
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 User image Pulsebot 2016-06-17 09:44:14 PDT
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
Comment 70 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-06-17 11:31:27 PDT
Sorry, reftest fuzz order was incorrect for that test. Will fix and reland when I get back.
Comment 71 User image Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) 2016-06-17 13:02:20 PDT
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.
Comment 72 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:11:23 PDT
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 73 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:18:42 PDT Comment hidden (mozreview-request)
Comment 74 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:18:42 PDT Comment hidden (mozreview-request)
Comment 75 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:18:42 PDT Comment hidden (mozreview-request)
Comment 76 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:34:02 PDT Comment hidden (mozreview-request)
Comment 77 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:34:02 PDT Comment hidden (mozreview-request)
Comment 78 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:35:30 PDT
Due to bug 1296086, test_acceleration.html has been flagged TODO (as we only accelerate on TaskCluster tests).

Thanks!
Comment 79 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:57:09 PDT
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
Comment 80 User image Andrew Comminos [:acomminos] (back to classes, will be slow) 2016-08-18 17:58:05 PDT
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
Comment 81 User image Nicolas Silva [:nical] 2016-08-19 03:01:19 PDT
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
Comment 82 User image Pulsebot 2016-08-19 07:39:53 PDT
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
Comment 84 User image Shahar Or 2016-08-20 14:21:08 PDT
Thank you!
Comment 85 User image albertogomezmarin 2016-08-26 03:08:05 PDT
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
Comment 86 User image stan 2016-09-10 21:33:45 PDT
I think I was bitten by the fix for this ticket.  Details here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1299588
Comment 87 User image Ciprian Muresan [:cmuresan] 2016-09-20 05:42:00 PDT
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.
Comment 88 User image Marco Castelluccio [:marco] 2016-09-20 05:43:32 PDT
(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.
Comment 89 User image Ciprian Muresan [:cmuresan] 2016-09-20 05:51:21 PDT
(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.
Comment 90 User image Marco Castelluccio [:marco] 2016-09-20 05:59:34 PDT
(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.
Comment 91 User image Clemens Eisserer 2016-10-17 02:07:42 PDT
Would it make sense to add bug 1306912 to the "depends on" list?
Comment 92 User image Botond Ballo [:botond] [standards meeting Feb 27 - Mar 4] 2016-10-17 10:00:59 PDT
(In reply to Clemens Eisserer from comment #91)
> Would it make sense to add bug 1306912 to the "depends on" list?

Yes, done.
Comment 93 User image Clemens Eisserer 2016-10-17 11:29:22 PDT
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.
Comment 94 User image Milan Sreckovic [:milan] 2016-12-14 11:09:29 PST
Lee, please reopen this once you fix bug 1323284, turning acceleration off by default.
Comment 95 User image Lee Salzman [:lsalzman] 2016-12-15 18:38:09 PST
As part of bug 1323284, we disabled acceleration again until we have time/resources to better investigate this. Reopening...

Note You need to log in before you can comment on or make changes to this bug.