I'm happy to report that the layers refactoring has landed on Mozilla central and is now in Nightly. We have already fixed a bunch of bugs (WebGL on b2g, plugins on Android, b2g tests, fixed position layers, ...) and are working on more. But, nothing seems insurmountable and it looks like the refactoring will stay landed.
We've tried to document the new system in the classes. The best place to start is gfx/layers/Compositor.h. To give an overview of the changes, there is now only one kind of layer on the compositor thread - composite layers, and one layer manager. These use a compositor interface to actually do the compositing, and there are (or will be) multiple compositor backends (see gfx/layers/opengl/CompositorOGL.h, for example). To implement a new OMTC backend, you should only have to implement a Compositor and one or more TextureHost, possibly also a TextureClient. There are other changes to how basic layers on the content thread interact with layers on the compositor thread. If it is not clear from the docs what is going on, please let me (nrc on irc) or nical know and we'll try to improve the docs!
We would love some help getting this tested! The easiest way is to simply use Firefox nightly for Android. If it crashes we should see it in the crash reports. If you notice anything rendering incorrectly, please either file a bug or let us know via irc (or even leave a comment here). You don't need to set any prefs etc. for Android, you will automatically get the refactored version.
We are most worried about FirefoxOS/b2g because that is where we use the most esoteric code paths and have the least automated testing. If you are working on b2g and are able to help us by running b2g built with m-c rather than one of the b2g branches, that would be great. Again, no prefs necessary, just using m-c is enough.
If you are on Linux and Mac and are feeling brave, then you can help us by running Firefox with OMTC on these platforms. Please bear in mind that this setup is unsupported for now and is known to be buggy and missing some features (plugins, for example). The most useful thing would be to compare Aurora (no refactoring) to Nightly (with refactoring) and let us know if anything has got worse. For both platforms you must set the pref "layers.offmainthreadcomposition.enabled" to true (in about:config). For Linux, you must be able to run normally with OpenGL with no issues, to do this you need to set "layers.acceleration.force-enabled" to true. If you have not tried this before, I would try it before trying OMTC, there is lots of driver sadness around. For Linux you must also set the environment variable "MOZ_USE_OMTC=1". Note that when using OMTC, about:support will report the layers backend for the content thread only, i.e., it will not really be true, it will appear that you do not have HWA, when you do.
Finding bugs for us to fix is much appreciated!
Finally thank you to everyone working on mozilla-central for your patience whilst we fix(ed) bugs, we appreciate it! And thank you to all the graphic team for their help getting this planned, written, finished, reviewed, and landed.
We've tried to document the new system in the classes. The best place to start is gfx/layers/Compositor.h. To give an overview of the changes, there is now only one kind of layer on the compositor thread - composite layers, and one layer manager. These use a compositor interface to actually do the compositing, and there are (or will be) multiple compositor backends (see gfx/layers/opengl/CompositorOGL.h, for example). To implement a new OMTC backend, you should only have to implement a Compositor and one or more TextureHost, possibly also a TextureClient. There are other changes to how basic layers on the content thread interact with layers on the compositor thread. If it is not clear from the docs what is going on, please let me (nrc on irc) or nical know and we'll try to improve the docs!
We would love some help getting this tested! The easiest way is to simply use Firefox nightly for Android. If it crashes we should see it in the crash reports. If you notice anything rendering incorrectly, please either file a bug or let us know via irc (or even leave a comment here). You don't need to set any prefs etc. for Android, you will automatically get the refactored version.
We are most worried about FirefoxOS/b2g because that is where we use the most esoteric code paths and have the least automated testing. If you are working on b2g and are able to help us by running b2g built with m-c rather than one of the b2g branches, that would be great. Again, no prefs necessary, just using m-c is enough.
If you are on Linux and Mac and are feeling brave, then you can help us by running Firefox with OMTC on these platforms. Please bear in mind that this setup is unsupported for now and is known to be buggy and missing some features (plugins, for example). The most useful thing would be to compare Aurora (no refactoring) to Nightly (with refactoring) and let us know if anything has got worse. For both platforms you must set the pref "layers.offmainthreadcomposition.enabled" to true (in about:config). For Linux, you must be able to run normally with OpenGL with no issues, to do this you need to set "layers.acceleration.force-enabled" to true. If you have not tried this before, I would try it before trying OMTC, there is lots of driver sadness around. For Linux you must also set the environment variable "MOZ_USE_OMTC=1". Note that when using OMTC, about:support will report the layers backend for the content thread only, i.e., it will not really be true, it will appear that you do not have HWA, when you do.
Finding bugs for us to fix is much appreciated!
Finally thank you to everyone working on mozilla-central for your patience whilst we fix(ed) bugs, we appreciate it! And thank you to all the graphic team for their help getting this planned, written, finished, reviewed, and landed.
19 comments:
Was OMTC the motivation for the refactoring? And is the motivation for OMTC that it will improve responsiveness? I'm just trying to understand this change from a high level.
Great work, Nick and team!
From bugzilla, i see there is still some post-landing stuff left to do.
What is the next step after the refactoring work is done? (specially for windows7)
I don't see a
layers.offmainthreadcomposition.enabled
pref on nightly? I do have some prefs with similar names and stuff about animation.
Anonymous: The motivation is to make it easier to bring OMTC to non-OpenGL platforms and also to pay off some technical debt - some of the code that went was really crufty.
Them motivation for OMTC is improved responsiveness and, on mulit-core platforms, improved performance. It is also a step towards doing a whole bunch of other graphics stuff off main thread, e.g., OMTA, async video, which have responsiveness and perf wins of their own.
Mayankleoboy: thanks! Yes, we have a bunch more (much smaller) refactorings to do and some bugs to fix.
Bas has made great progress on the D3D11 backend for OMTC on Windows metro. We'll be looking at D3D9 and/or 10 backends pretty soon to try and bring OMTC to desktop Windows. There are a whole bunch of issues on desktop though, plugins being number one.
On Mac, Matt Woodrow has been putting some work in, so hopefully OMTC as a supported platform there is not too far off.
azakai: it should be there, you can just add it if it's not. The animation ones are for OMTA.
"Bas has made great progress on the D3D11 backend for OMTC on Windows metro"
AFAIU, this means that (in the short term), OMTC on Windows will be available only if
a) you use windows8
b) you use windows8 and FF in the Metro mode
c) you have a DX11 capable GPU.
Does the D3D11 backend support Win7 users who have a DX11 capable GPU ?
BTW, is there anything in the DX11.1 API that is particularly interesting ?
mayankleoboy1: the d3d11 work is specifically targeted for the Firefox Metro browser which is currently being worked on. Initially, d3d11 OMTC will only be available there, not even on regular Firefox on Windows 8. The reason is that the Metro browser is essentially a mobile browser so has to support less in terms of plugins and so forth, but more in terms of touch (pan/zoom etc.) which requires OMTC to be really smooth.
So, initially at least, Windows users on 7 or 8 even with a d3d11 gpu will not be able to make use of the d3d11 OMTC backend.
As for anything interesting in DX11.1, I'm not sure, I haven't really looked at it, sorry.
Resizing the window a lot on linux causes these
https://crash-stats.mozilla.com/report/index/bp-393db86b-5308-4b09-8803-4e09e2130416
https://crash-stats.mozilla.com/report/index/bp-9ad04eed-4409-4534-a719-9bead2130416
johndrinkwater: thanks for testing and for the crash reports! I'll try to reproduce some time today.
johndrinkwater: I could not reproduce a crash by resizing on Linux. Were there any particular URLs where the crash happened?
Nothing special, it can happen on the start page with no new url.
I think I just found out why; I have Steam (linux native client) running which is using OpenGL to render, once I closed that firefox no longer crashes.
https://gist.github.com/johndrinkwater/4721913 sysinfo for anything else useful
johndrinkwater: thanks for the bug report, I filed bug 864628.
johndrinkwater: if you are able to provide a stack trace and post it to that bug, it would be really useful, thanks! Instructions here: https://developer.mozilla.org/docs/How_to_get_a_stacktrace_for_a_bug_report
Got a black window on enabling OMTC on Nightly Linux x64 by setting MOZ_USE_OMTC=1 and
layers.offmainthreadcomposition.animate-opacity=true
layers.offmainthreadcomposition.animate-transform=true
layers.offmainthreadcomposition.enabled=true
layers.offmainthreadcomposition.log-animations=true
Graphics
Adapter Description Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
Device ID Mesa DRI Intel(R) Sandybridge Mobile
Driver Version 3.0 Mesa 9.1.1
GPU Accelerated Windows 1/1 OpenGL
Vendor ID Intel Open Source Technology Center
WebGL Renderer Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
AzureCanvasBackend cairo
AzureContentBackend cairo
AzureFallbackCanvasBackend none
And also set layers.acceleration.force-enabled=true
Anonymous: thanks for the report. It is currently broken for me too - I think this is a recent thing. You could wait a few days and try again, or try a nightly from a few days ago. If it still doesn't work I'll file a bug for you. Please let me know how you get on!
Do things work properly when you force OpenGL graphics, but don't turn on OMTC? I guess the about:support info is from restarting with OGL, but not OMTC, right?
http://www.marketwatch.com/story/transgaming-and-google-announce-swiftshader-licensing-agreement-2013-04-23-81733139
(i noticed a folder named swiftshader in Chrome directory).
I think mozilla should look into the advantages of using a CPU based 3D render where GPU acceleration is not available (due to drivers, usually).A modern quad core could be performing better than an integrated intel GPU.
Something related to LLVMpipe , or maybe even doing a partnership with Transgaming, ala Google ?
This is cool!
Post a Comment