Support software compositing for SWGL
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: lsalzman, Assigned: lsalzman)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
Attachments
(7 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
The initial use-case for SW-WR is users who for some reason can't rely on hardware support for WR, and for whom might otherwise be stuck on some form of Basic compositing without WR. Thus we need an equivalent level of software compositing for SW-WR with comparable coverage to Basic for the case for when the user's HW acceleration is just completely unreliable to fall back to. Currently SWGL does not support any such software compositing.
My goal in this bug is to restructure SWGL compositing so that these SWGL use-cases have representative RenderCompositors and to otherwise solidify the compositing interface for implementing SWGL compositors.
Accordingly Windows and Linux will be addressed via a hook into the existing Basic compositing infrastructure, whereas Mac will be addressed via NativeLayer infrastructure since it doesn't implement the same widget hooks for Basic.
Additional follow-up accelerated compositors for Windows and Linux could be investigated in a future bug if necessary.
Assignee | ||
Comment 1•5 years ago
|
||
For performance reasons in SWGL software compositors. to avoid unnecessary
full-screen copies of the framembuffer, we need to allow those compositors to
map their underlying widget surfaces and pass that buffer to SWGL so that they
can be directly rendered to. That also requires supporting custom strides, as
we can't always enforce the particular layout of the buffers handed off to us.
To that end, InitDefaultFramebuffer is generalized to take such information
and then many places where we rely on a specific hard-coded SWGL-calculated
stride have been altered to deal with a caller-supplied stride.
Assignee | ||
Comment 2•5 years ago
|
||
This is a first implementation of a software-only SWGL RenderCompositor
that relies on the existing widget hooks for Basic compositing. It attempts
to lock the widget and get a DT whose underlying data it can supply directly
to SWGL to composite to. Critically, it does not rely on OpenGL or any other
form of HW accel to function. The interface between the RenderCompositor and
SWGL will be further refined in follow-up patches.
Depends on D80267
Assignee | ||
Comment 3•5 years ago
|
||
RenderCompositors for SWGL that wish to provide accelerated compositing need to
subvert the existing Bind/Unbind hooks in the WR compositor. These compositors
need to keep track of their HW tiles without actually binding an OpenGL FBO
for WR to render picture cache tiles. SWGL needs to intervene and get a backing
buffer for tile from the RenderCompositor so that it can create a SWGL FBO for
WR to render the picture cache tile to.
To that end, this adds MapTile/UnmapTile as a replacement for Bind/Unbind for
those scenarios. This is done in a way that it affects only the WrCompositor of
webrender_bindings without actually altering WR's Compositor interface. This is
beneficial because WR does not have to understand the details of SWGL
integration and also so as not to complicate other users of WR such as Servo
who are not currently utilizing SWGL at all.
RenderCompositorOGL is initially modified to use these hooks in this patch. It
later became more convenient to restructure that in a follow-up patch.
Depends on D80268
Assignee | ||
Comment 4•5 years ago
|
||
RenderCompositorOGL currently have many responsibilities including supporting
OpenGL compositor for Linux, whole-window compositing for Mac NativeLayerCA,
and per-cache-tile compositing for Mac NativeLayerCA. With the additional of
support for SWGL, this becomes even further complicated.
It becomes advantageous to separate out RenderCompositorOGL specifically as
only the basic OpenGL compositing case, as that naturally yields a simple and
isolated RenderCompositor.
What is left over becomes RenderCompositorNative, a basis for implementing
NativeLayer-based RenderCompositors. To cleanly isolate state and details of
when HW compositing or SW compositing is being used, these are further split
off into RCNativeOGL and RCNativeSWGL versions that deal with specific
isolated details of OpenGL and SWGL respectively.
RCNativeOGL deals with just setting up OpenGL FBOs for NativeLayers.
RCNativeSWGL's new task is just to deal mapping NativeLayers and providing
SWGL FBOs for them without involving OpenGL.
Depends on D80269
Assignee | ||
Comment 5•5 years ago
|
||
Currently RendererOGL has mixed-in details of SWGL context creation which becomes messy
and slightly unanticipated based on the nomenclature and structure of RendererOGL. Based
on other work in bug 1646835, it becomes more natural to move this context creation into
the specific SWGL RenderCompositors so that RendererOGL can be agnostic to any SWGL
details.
Depends on D80270
Assignee | ||
Comment 6•5 years ago
|
||
Bug 1592038 implemented a means for reducing memory usage resulting from needlessly
duplicated allocation of depth buffers when rendering WR picture cache tiles via
the NativeLayer interface. This aims to keep a similarly level of memory savings
even when using NativeLayer + SWGL.
SWGL allows, as an extension beyond OpenGL, specifying an allocation size separate
from the incidental size of a texture, which can be used to render to a smaller
valid rect of a texture without continually reallocating it every time the size
of the valid rect changes within the actual tile size. This functionality is used
to keep around only a single depth texture for the SWGL compositor that is resized
to accommodate the maximum requested tile size, so that any surface or tile can
use it as desired.
Depends on D80273
Assignee | ||
Comment 7•5 years ago
|
||
Comment 9•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/671f7c62e83f
https://hg.mozilla.org/mozilla-central/rev/940b04835c81
https://hg.mozilla.org/mozilla-central/rev/826ac43a1fb5
https://hg.mozilla.org/mozilla-central/rev/e7a01d5a6ed3
https://hg.mozilla.org/mozilla-central/rev/9165aad9944f
https://hg.mozilla.org/mozilla-central/rev/1adde345073e
https://hg.mozilla.org/mozilla-central/rev/e5cfc0f5d9c5
Description
•