| Age | Commit message (Collapse) | Author |
|---|
|
As part of removing GL compositing, separate_rects.cpp is no long
needed. Use hwc_rect_t and hwc_frect_t in places instead of our own
class.
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
The GL based compositing adds alot of complexity and was only ever well
tested on closed stacks. It also only supports GLES3.x and still relies
on sw_sync timeline which is now a debugfs feature. Those are just the
known issues.
Removing the GL compositor means everything related to squashing layers
and pre-compositing can be removed. The planner is left as it may be
useful when adding back support for overlay planes. With this change,
only a single plane is supported until ValidateDisplay learns to do
atomic modesetting test for overlay planes.
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Clean up direct gralloc usage from generic code.
Because of gralloc0/gralloc1 difference, it should
be only used by platform* part.
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
|
|
Since HWC2 doesn't require the use of threads to implement correct
synchronization, remove some of these threads.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
|
|
Add support for out-fences through the OUT_FENCE_PTR property.
Out-fences signal when their associated buffer may be read by a device.
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
|
|
Use the new Planner interface to handle the layer->plane mapping.
This allows us to simplify the Plan() function by offloading the
plane provisioning to the platform specific code.
BUG=b/28117135
TEST=Tested on ryu with a variety of window layouts/workloads
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I75a0c5d87a9096e7a83ecbc848c75fee42ee1131
|
|
This patch introduces a new Planner interface to the platform specific
code. This new interface will allow for platform-specific plane provisioning
decisions to cover various hardware quirks.
Each platform must provide a Planner with one or more PlanStage steps. These
stages are run in order and are used to move the given layers onto composition
planes.
There are two generic stages provided by the platform:
- Protected: Places layers on dedicated planes
- Greedy: Provisions as many layers to planes and sticks the rest in precomp
There is also one platform-specific stage included:
- ProtectedRotated: Places any protected & rotated layer on the primary plane
BUG=b/28117135
TEST=Tested on ryu with a variety of window layouts
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ib6062ab4779166753afaf122450bb63126bf9161
|
|
Simplify the SquashAll() function by generating the composition
without using Plan(). This allows us to specify exactly what we
want on the screen without involving the normal plane provisioning
code.
BUG=b/28117135
TEST=Tested on ryu, squashing still works
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ieec9c323941e2a80252b33d14563c4d218d38dfb
|
|
Instead of passing a bunch of member data to a static function, make
SeparateLayers a member of DrmDisplayComposition. This will be simplified
further once the Planner interface is implemented.
BUG=b/28117135
TEST=Tested on ryu
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ia4e15aa20b6dc14b044ee1dec7b5fce514278be7
|
|
Now that DrmCompositionPlane is classified, move the type into it
as a subclass.
BUG=b/28117135
TEST=Tested on ryu
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I774f477e75b3a2e2916c5d98931730dac46d3877
|
|
Instead of a 1:1 mapping of layer:plane, use a vector to store
source layers for a composition plane. This will allow us to
represent squash compositions more easily by adding all source
layers to the vector.
This should also facilitate hardware which allows multiple fbs per plane.
BUG=b/28117135
TEST=Tested on ryu
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I5d4bfc6e9da022eaab047f948cc874d6a8a25746
|
|
Instead of encoding the plane/composition type in source_layer,
move it to its own explicit type. This will allow us to expand
source_layer to include more than one layer.
BUG=b/28117135
TEST=compiles and runs on smaug
Change-Id: I19b1ed8e395347bbefb0fb6a0ab02d6ac0e5c1c1
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
We're going to need more platform-specific stuff, so lump it
all in the same header.
BUG=b/28117135
TEST=compiles
Change-Id: Idfe82e9a29a0bcd284a02b2e58af0e620fdc542b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
A cleanup patch to fix the build warnings that have surfaced
from the new build system.
BUG=None
TEST=Builds without warnings
Change-Id: I2ad898e627d451f87705d2bdf06a315b8e1c7a1c
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Do not check the composition with kernel for every frame. We are currently
using synchronous atomic ioctl calls, so all test-only calls are serialized
with the actual commits.
BUG=25866352
TEST=same test procedure as crosbug.com/p/47206
Change-Id: Ia423243c279fc677ff6213115a8f20efa40c235e
|
|
Protected layers will not work inside of the GLWorker, so we are forced to put
them into planes directly.
Because we can now receive display contents which can never be properly
composited (e.g. 4 protected layers on hardware with only 3 planes), some
compromises had to be made for the composition planning algorithm. First all
protected layers are given a plane. Then the remaining planes are used by the
remaining layers, pre-composite buffer, and squash buffer. In the case where
there are too few planes for both a pre-composite buffer and squash buffer,
everything gets pushed into the pre-composite buffer and the squash buffer
will not be composited onto the screen. Another major limitation is that any
unprotected layers appearing behind a protected layer will actually appear on
top of that protected layer.
BUG=chrome-os-partner:43674
TEST=run protected content with lots of other layers
Change-Id: I94620d93f68ca14dc1966422dc89035ab84e3ff4
|
|
That's the second most important part of renaming a file.
Change-Id: If9280f3b360389ef17b798e162a9c3b0c0a3133b
|
|
Change-Id: Ifd4feaa0de303ddfd519d4415ab31d2a72f26022
|
|
Also fixes hwc_dump sometimes failing to null terminate its output buffer.
TEST=dumpsys SurfaceFlinger
Change-Id: Ibf93cfd496a07a9375d78a8b239c2c7876aff986
|
|
This patch rearranges things to make squashing possible.
The high-level changes:
- A new Plan phase that happens in QueueComposition. This is where the
overlay allocation is moved to. It's also the only safe time that
the composition can try to plan squashing. This is because squashing
depends on the exact ordering of compositions.
- GLWorker now renders regions rather than layers. A region in this case is
a clipping rectange and set of layers that are to be rendered in that
rectangle. This is always what GLWorker did in the end, but now the work
to seperate layers into regions is done externally. This was changed
because the output of SquashState is a list of stable regions that need to
be put through GLWorker
The Plan methods of the Compositions are responsible for updating per-display
SquashState and for allocation regions/layers to squashing, pre-composition, or
hardware overlay. Because of the drastic changes to how composition planning
works, it was necessary to bundle it with the GLWorker change.
This change also includes plenty of other refactorings that were deemed to
be too painful to try and seperate into another change.
Change-Id: Ie7bfe077067e936a0862a07cbe87b525eab8d4f8
|
|
This patch queues modeset in the compositor for application on
the next frame. This allows us to perform the modeset atomically
with the first frame that comes in after the mode is changed.
Change-Id: I6bb9edd17bbdd6dbee5c0474f2e43599781cc7a7
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This is a sweeping change to discard our usage of struct hwc_layer_t outside
hwcomposer.cpp. That was a dangerous struct that was a source of many of our
errors. Replacing it with safer RAII-style classes reduces the amount and
complexity of our code.
Change-Id: I580cafdf89bd1e7e6583f3073858b8e78e6018ba
|
|
Having frame number in the composition is very useful for
debugging transient issues, plumb it through the drm compositor
stack.
Change-Id: Ibc7555c89bea79c580b3201b11db4ced6360efb9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This commit contains a lot of churn because it changes code to use automatic
resource lifetimes as much as possible. As more things get changed, this is
essential to maintaining stability.
In addition, this change changes how layers are passed through the compositor
API. Before each layer was passed down one at a time. Now they are passed in
all at once. This is simpler for the implementation because it makes errors
more atomic and makes decisions easier for the compositors.
Change-Id: Ic3e6b5d0089fb1631ea256adcce9910ed8f38366
|
|
This is needed because SF will sometimes release buffer_handles before GL gets
to using them for composition.
Change-Id: I01db0975cc82d6b59bf4f9521a24071baf89c38a
|
|
DrmDisplayCompositor
Change-Id: Id3a6deea9fc0f97640b34dacb25d36f3793f2d4e
|
|
composition""
This reverts commit cbe9c01336e23a63259db65d22d63d6a697b8813.
|
|
This reverts commit 2317bb19d8663efc31e6fcd8cf7fd2a73577253d.
For now until we figure out a more stable SF/hwc
Change-Id: Ia5ca089610a487bf036a1ddd5fb62e504e02ad98
|
|
To accomplish this a few things changed:
- DrmComposition::GetRemainingLayers always returns the number of planes needed
- DrmComposition::AddLayer succeeds even if no DrmPlane was found for it
- DrmDisplayComposition::AddLayer has overload that imports the given buffer
- GLWorkerCompositor has a function to finish its composite before returning
Put together this change makes DrmComposition always accepts all layers given to
it even if it means some of those layers are assigned a NULL DrmPlane. The
DrmDisplayCompositor will scan its given layers for any that are missing planes.
In such a case, a DrmPlane is stolen from the last layer to receive a plane.
Then all layers in the DrmDisplayComposition that have no planes (including the
one stolen from) are composited synchronously using a GLWorkerCompositor and a
new layer is generated from the results. That layer is added to the
DrmDisplayComposition using the new import AddLayer function and the stolen
DrmPlane. DrmDisplayCompostior then continues as usual.
Change-Id: Ia6477c210c8f1307a4e537bec46889110d79ca18
|
|
This change will release the layers passed back to SurfaceFlinger even on an
error in the compositor thread.
Change-Id: I22f622855c8c953a058b4a08d0af1ae427e4cbbd
|
|
Right before queuing up a composition, go through the
list of unused planes and add disable markers such
that they don't remain active when the new frame is
posted.
BUG=chrome-os-parter:42311
TEST=Tested on smaug, turned on/off bunch of times, no dup icons
Change-Id: Ic2e5e210873efb6dc41fd43682fe00db33c2a28e
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This patch changes the behavior of DPMS in hwcomposer from
applying asynchronously/immediately, to queuing in the
compositor and being processed in order. This is desirable
for a couple of reasons:
1- It ensures all frames set before set_power_mode are
shown on the screen before it turns off
2- We make sure we don't rmfb a framebuffer that is
currently applied to a disabled crtc.
The second reason above can cause the display to turn back
off once it's on since the fb will dereference to zero in
the kernel and it will disable the pipe without notifying
us.
Change-Id: I2aab9ee0353b12fecced46766ed2dbb64f0aef4b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This allows us to have different types of compositions. This will
enable injection of non-frame related compositions such as dpms
and mode.
Change-Id: Ia62421c114c0c6bebccef3ce6ae936366b6aafe2
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This patch splits out the current single drm compositor with
per-display compositors, each with their own thread.
The per-display compositors are hidden behind a singleton
drm compositor. This allows us to maintain a whole-world view
of all displays involved in a frame. This becomes useful if
we start switching up crtcs/encoders for the displays.
This also allows us to issue one DrmComposition when the
frame is being assembled.
The single DrmComposition handles the plane allocation (since they
might switch between displays), and contains per-display compositions
which are used to store the layer->plane/crtc information for each
frame. The display compositors use the per-display compositions to
display the frame on their output.
Each display compositor receives a shared pointer to the frame's
DrmComposition on QueueComposition. As a result, both the composition,
and the per-display compositions, live for as long as any one
display is still using it. While this is sub-optimal (since a display
might never update again), this is probably fine for now.
Finally, splitting things up per-display will allow us to inject
non-compositing jobs into the composite queue. An example would be
turning the display off, or setting the mode. This ensures that all
frames in the composite queue are displayed before the mode changes
or the display is disabled.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I8a233ea64710b238f70acbcde1f6d771e297b069
|
