[Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: jrmuizel, Assigned: acomminos)
References
(Blocks 1 open bug)
Details
(Whiteboard: [k9o:p?:fx?] [games:p-])
Attachments
(5 files)
(deleted),
patch
|
joe
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
(deleted),
text/x-review-board-request
|
nical
:
review+
|
Details |
(deleted),
text/x-review-board-request
|
nical
:
review+
|
Details |
(deleted),
text/x-review-board-request
|
nical
:
review+
|
Details |
No description provided.
Reporter | ||
Updated•14 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•14 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
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•14 years ago
|
||
Should probably depend on bug 594308 and bug 580410, too?
Comment 5•14 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.
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•14 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 9•14 years ago
|
||
Requesting blocking betaN+ or beta7+ if we want feature parity with Mac for OpenGL (bug 580405). Joe Drew?
Comment 10•14 years ago
|
||
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•14 years ago
|
||
Thanks for the info Joe. That's pretty much what I expected, unfortunately.
Comment 12•14 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•14 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)
Comment 14•14 years ago
|
||
I get this in my mail - What |Old Value |New Value ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
Comment 15•13 years ago
|
||
We also need to make sure this gets disabled in the aurora branch next week, what do I need to do to track that?
Updated•13 years ago
|
Comment 16•13 years ago
|
||
I did enabled hardware acceleration, but I got half the FPS to that in chromium.
Updated•13 years ago
|
Comment 17•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Matt, was this orange on try?
Comment 20•13 years ago
|
||
Not when I last tried it, but it may have been when texture_from_pixmap was broken.
Comment 21•13 years ago
|
||
Rebased and fixed the mochitest for this change. Carrying forward r=joe
Comment 22•13 years ago
|
||
Looking good on tryserver, trying this again! http://hg.mozilla.org/integration/mozilla-inbound/rev/0a920411e64c Fingers (and toes) crossed.
Comment 23•13 years ago
|
||
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 24•13 years ago
|
||
Backed out on inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/7797172fc164 http://hg.mozilla.org/integration/mozilla-inbound/rev/955f83dc4372
Comment 25•13 years ago
|
||
Note that Talos reported massive perf regressions on Linux for the push this was part.
Comment 26•13 years ago
|
||
... for the push this was part of. I see that Matt filed bug 680817 on this.
Updated•13 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Comment 27•12 years ago
|
||
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•12 years ago
|
||
(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•12 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.
Comment 30•12 years ago
|
||
(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•12 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•12 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 ?
Comment 33•12 years ago
|
||
(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•12 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•12 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
Comment 37•12 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•12 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•12 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•12 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•12 years ago
|
||
ivybridge i5-3210m 2.53ghz, 8gb ram on ubuntu 12.10
Comment 42•12 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•12 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/
Comment 44•11 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.
Updated•10 years ago
|
Comment 47•10 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
Comment 48•10 years ago
|
||
(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•10 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)
Comment 50•10 years ago
|
||
(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•10 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?
Comment 52•10 years ago
|
||
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•10 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•10 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•10 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•9 years ago
|
Comment 56•9 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.
Comment 57•9 years ago
|
||
(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•9 years ago
|
||
(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•9 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
Comment 60•9 years ago
|
||
(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
Assignee | ||
Comment 61•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/59522/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59522/
Assignee | ||
Comment 62•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/59524/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59524/
Assignee | ||
Comment 63•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/59526/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59526/
Assignee | ||
Comment 64•8 years ago
|
||
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•8 years ago
|
||
Comment on attachment 8763264 [details] Bug 594876 - Accelerate layers by default for nightlies on Linux. https://reviewboard.mozilla.org/r/59526/#review56620
Comment 66•8 years 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
Updated•8 years ago
|
Comment 67•8 years 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•8 years 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
Comment 69•8 years ago
|
||
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
Assignee | ||
Comment 70•8 years ago
|
||
Sorry, reftest fuzz order was incorrect for that test. Will fix and reland when I get back.
Comment 71•8 years ago
|
||
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.
Assignee | ||
Comment 72•8 years ago
|
||
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) |
Assignee | ||
Comment 78•8 years ago
|
||
Due to bug 1296086, test_acceleration.html has been flagged TODO (as we only accelerate on TaskCluster tests). Thanks!
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 79•8 years 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
Assignee | ||
Comment 80•8 years 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
Comment 81•8 years 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
Comment 82•8 years 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
Comment 83•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/314eb9761599 https://hg.mozilla.org/mozilla-central/rev/f35636ae9fdb https://hg.mozilla.org/mozilla-central/rev/32fd2e8a3be8
Comment 84•8 years ago
|
||
Thank you!
Updated•8 years ago
|
Updated•8 years ago
|
Comment 85•8 years 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
Comment 86•8 years ago
|
||
I think I was bitten by the fix for this ticket. Details here: https://bugzilla.mozilla.org/show_bug.cgi?id=1299588
Comment 87•8 years ago
|
||
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•8 years ago
|
||
(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•8 years ago
|
||
(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•8 years ago
|
||
(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•8 years ago
|
||
Would it make sense to add bug 1306912 to the "depends on" list?
Comment 92•8 years ago
|
||
(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•8 years 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.
Lee, please reopen this once you fix bug 1323284, turning acceleration off by default.
Comment 95•8 years ago
|
||
As part of bug 1323284, we disabled acceleration again until we have time/resources to better investigate this. Reopening...
Updated•8 years ago
|
Updated•8 years ago
|
Comment 96•7 years 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.
Comment 97•7 years ago
|
||
(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•7 years 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•7 years 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.
Comment 100•7 years ago
|
||
What's the status/forward plan here? I see quite a few dependencies however it's a bit unclear how many of them are blocking enabling by default and which could be dealt with afterwards (or while riding the trains). Do you have a rough time estimate (in terms of trains) when you think this is worthwhile to pick up (i.e. enable by default)?
No current timeline or solid plans.
Comment hidden (off-topic) |
Comment 103•7 years ago
|
||
Is this meaning linux version won't get webrender? (as it need HW_COMPOSITING to work)
Comment 104•6 years ago
|
||
I think the importance of this issue should not be underestimated. It has a direct impact on "user-experience", and "user-experience" has a direct impact on market share. I know, because I was even considering switching over to Windows just so I could use the Microsoft Edge browser. Why? Because for years I've watched on in envy as my work colleagues smoothly scrolled around the heaviest of web pages on the Interwebs. It's like they were gliding on ice, while my scrolling made it look like skating on cobble stones. On Kubuntu 18.04 (on 3 computers), I went in to about:config and set layers.acceleration.force-enabled to true. The difference is like night and day. Moving back to Windows is something I really didn't want to do, and thankfully, I don't have to now because I too am skating on ice. I still get the odd "jank" ("micro-stutter" - whatever it's called), but it has become the exception rather than the rule. I know that "smoothness" can be very subjective, but here's the test I use: 1. Open Google's homepage. 2. Click on the "Images" link. 3. Do an image search for something (e.g. "cars"). 4. Click on the middle-button to activate auto-scroll. 5. Move the mouse cursor about 1cm below the "auto-scroll circle. 6. Just observe the page as it scrolls downwards. On a default installation of Kubuntu 18.04 on: * My desktop (with an Nvidia 1070 with 6GB of RAM) * My T470 laptop (with an Intel 520 iGPU) * My T470p laptop (with an Nvidia 940mx with 2GB of RAM) performing the above steps results in jittery and jerky scrolling - in other words, a terrible user-experience. Such an issue (and I do believe it's an important issue) is not easy for the average user to articulate. Their brains perceive something is wrong and not working "quite right", but they don't know how to explain it and they simply form a negative opinion. Many years ago Intel commissioned a project whereby they reverse engineered the iOS user-experience (they wanted to find out why Apple was so successful, despite running on lower-end hardware and slower CPUs with less cores). The conclusion was definitive: * The operating system managed to consistently maintain 60 frames per second. * There was only 6 (or so) milliseconds of touch input lag (compared to Androids whopping 200ms in some cases). That is the secret sauce - a successful implementation of the whole "touch paradigm". The same can be applied to the desktop experience, although with the desktop experience input lag isn't as important (most of the time). Make the experience "smooth", and users "feel" good. Hardware acceleration is imperative to achieve this!!
Comment 105•6 years ago
|
||
(Just a community member) (In reply to Scott Deagan from comment #104) Hi, I think nobody will touch this old feature. I share your position and there's light at the end of the tunnel! > managed to consistently maintain 60 frames per second. That's exactly why you want to try out WebRender: https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true, restart. It's developed in Rust (https://www.rust-lang.org), so it's more secure, it's also using OpenGL and there is a project porting it to Vulkan, DX12 and Metal based on an abstraction layer. Presumably, it will be enabled by default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and Android will follow afterwards. You might want to follow: * https://mozillagfx.wordpress.com/ * https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx * https://github.com/servo/webrender/
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 108•6 years ago
|
||
development-in-progress |
Yeah, exotic, old and mobile configurations can't expect too much at the moment.
Comment 109•6 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105) Thanks! Good to know what's in the pipeline, but at the moment I have found a "solution" (?) that works for me right now. In the 10 years or so that I've been using Linux, this is the first time I have experienced "buttery smooth scrolling" - and while some may dismiss this as being "just scrolling", to me it makes all the difference. Again, it's subjective because it's "user-experience", but I'm sure others will be negatively impacted the same way I was. Anyway, my point is I consider myself a fairly advanced user, and it took me 10 years to finally achieve something I've been wishing for since I started using Linux. It would be nice if "smooth" was the default, and not something users have to find very technical configuration tweaks to achieve (because most users won't). I'll have a read about WebRender and will try it out. Again, thanks for pointing this out.
Comment 110•6 years ago
|
||
"Other graphics cards, Linux, Mac and Android will follow afterwards" I sure hope so, but we've been told this before. The old opengl layers were supposed to be enabled on linux 'eventually' too, but it never happened, and in 2018 linux users are stuck without any hardware acceleration by default.
Comment 111•6 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105) > Hi, I think nobody will touch this old feature. I share your position and > there's light at the end of the tunnel! > > > managed to consistently maintain 60 frames per second. > > That's exactly why you want to try out WebRender: > https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true, > restart. > > It's developed in Rust (https://www.rust-lang.org), so it's more secure, > it's also using OpenGL and there is a project porting it to Vulkan, DX12 and > Metal based on an abstraction layer. Presumably, it will be enabled by > default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and > Android will follow afterwards. Since WebRender deepends on hardware compositing, isn't enabling WebRender by default on Linux blocked on this bug?
Comment hidden (advocacy) |
Comment hidden (me-too) |
Comment hidden (advocacy) |
Comment hidden (me-too) |
Updated•5 years ago
|
Comment 117•5 years ago
|
||
ogl-linux-beta
Turn on OpenGL accelerated layers by default for at least some subset of hardware
This bug is basically a wontfix:
// Hardware compositing should be disabled by default if we aren't using // WebRender.
https://hg.mozilla.org/mozilla-central/rev/74e4704a550e
If the GPU process becomes disabled due to crashes, then we should not allow Linux to fallback from WebRender to OpenGL compositing in the parent process. It should instead fallback to software just like Windows. This is important because we don't support the OpenGL compositor configuration.
Test WebRender
Beta and Stable might have bugs that are already fixed on Nightly.
Please download https://nightly.mozilla.org, open about:config, set gfx.webrender.all to true to force-enable WebRender, then restart Nightly.
If you see a problem, please file a new bug report. Open about:support, click on "Copy text to clipboard", paste it into a text file and attach it to the report. Thanks! Your graphics card must support at least OpenGL 3.1. Known Linux-only bugs are tracked here. On Nightly, WebRender is already enabled by default for modern Intel and AMD with Mesa 18.2 or newer with screens smaller than 4K.
Comment 118•5 years ago
|
||
I'm currently using layers.acceleration.force-enabled=true with Linux Mint 18.3 (Ubuntu 16.04) and it works flawlessly with my Intel Haswell iGPU. It worked fine in Linux Mint 17.3 (Ubuntu 14.04) as well.
Does comment #117 mean that I should revert it to false and rather set gfx.webrender.all=true now?
Comment 119•5 years ago
|
||
If you enable gfx.webrender.all
, then layers.acceleration.force-enabled
should have no effect. You can try to see which works better for you.
Comment 120•5 years ago
|
||
Is there a particular bug report dedicated to 4K screens?
Comment 121•5 years ago
|
||
(In reply to Mauro Molinari from comment #118)
Does comment #117 mean that I should revert it to false and rather set gfx.webrender.all=true now?
If you are using Nightly, then yes (but please update at least to Ubuntu 18.04 LTS!), otherwise rather not/at your own risk. Better force-enable WebRender only with Nightly for now. If you wanted to try it out with Beta, please check by yourself if bugs are already fixed on Nightly.
(In reply to Dmitry Gutov from comment #120)
Is there a particular bug report dedicated to 4K screens?
No, not one particular. Ctrl+F "4k": https://mozillagfx.wordpress.com/2019/04/30/webrender-newsletter-44/
Updated•5 years ago
|
Comment 122•4 years ago
|
||
I think it depends on 1659143.
Comment 123•3 years ago
|
||
Taking the freedom to close this - accelerated layers are going away in favor of Webrender, which is tracked in bug 1491303.
Description
•