| 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>
|
|
This reverts commit 3b0c69d3477d3601b1dbcb75fdd748254e297e7e.
|
|
The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.
Unfortunately, due to these optimizations, the drm_hwcomposer's
pre-compositor becomes somewhat hardware specific (originally
targeting nvidia hardware, I believe).
So on some hardware, the gl precompositor may not actually
initialize due to hardware missing features, or the hardware
supporting different shader APIs.
Rather then try to rework the drm_hwcomposers precompositor
to be more generic, I instead suggest that when the
precompositor fails to initialize, we simply fall back to the
already more widely compatible client compositor in
SurfaceFlinger.
Thus, this patch cleans up some of the precompositor
initialization, which didn't handle failures well.
Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
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>
|
|
If we drop a frame while compositing, free the active composition.
Assume a frame pipeline of A->B->A. If we drop frame B, it will become
the active composition, which means the fences for A will not be released,
causing us to block A on A --> DEADLOCK.
BUG=b/29122961
TEST=Tested on smaug, no longer hangs
Change-Id: I98817bb361f1d0669395ddac5d96cf4f19d4b26a
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Previously, we would only test the first frame when the geometry
changed. However, if SF sent us the same composition with different
FBs, we could end up sending invalid frames to the kernel.
This change saves the result of the atomic_test between geometry
changes so we avoid using hw composition for all invalid frames.
Bug: 25866352
Test: Tested on smaug, observed squashes between geometry changes
Change-Id: I3b5d9e83a870481bf2e6869900eafaf0ca66a0d5
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Before we send a composition to the frame worker and display, run it
through the kernel to test whether it can be put on hardware. If the
kernel rejects the composition, use the squashing code to flatten it
on one layer and send the result to the frame worker.
Bug: 25379136
Test: Tested on smaug, frames were squashed, fun was had
Change-Id: Icac3c034d0eb4c0becbdc0f8ace1de75ab8ae2b8
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Split the SquashAll function into SquashAll and SquashFrame. This
will allow us to squash arbitrary compositions without using the
active composition or applying it to the screen.
Bug: 25379136
Test: Tested on smaug
Change-Id: I1767f731e14f36540151556ce07373848b604030
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Allow the caller of CommitFrame to run the commit in "test only" mode
which will send the frame to the kernel, but won't actually change any
registers.
Bug: 25379136
Test: Tested on smaug
Change-Id: I831b5f17d433bc60d9f107689feb1d7672c100a9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Instead of creating the mode blob right before doing the modeset,
create it as soon as the modeset is queued. This will allow us to
use the blob for both atomic test as well as commit.
In addition to keeping the blob around, store the blob's id while
the mode is active so we don't need to look it up when/if the next
modeset comes in.
Bug: 25379136
Test: Tested on smaug
Change-Id: I60e6f83310ea0601388bb31b63d25c6fd7b8fc4d
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
DrmDisplayCompositor::SquashAll is triggered after a constant timeout in
DrmCompositorWorker::Routine. It will not be triggered more than one time
between genuine hwc_set calls. SquashAll has no effect if there are protected
layers, only one layer, or any errors. On success, SquashAll produces a new
DrmDisplayComposition that owns the layers in the planes of the active
composition and makes that the new active composition. SquashAll has no effect
on SquashState.
Change-Id: I975edb21847dcf2d93245f92a6e53a4e366c6a3b
|
|
It is spelled "separate", not "seperate".
Change-Id: Id92d12aba42989a8a72e4596d425b2a9eea4e5ec
|
|
That's the second most important part of renaming a file.
Change-Id: If9280f3b360389ef17b798e162a9c3b0c0a3133b
|
|
Apply "override" keyword and remove redundant "virtual" keyword.
Ran clang-format on all files.
Change-Id: I76730296aa8f52e555137d4b5973fa27d38f0aa6
|
|
We are currently using synchronous (blocking) atomic modeset calls
which unnecessarily delays GL.
BUG=25126188
TEST=check timestamp of SignalPreCompDone relative to hwc_set
Change-Id: Iba70c1c9591e467c1627516af123a43206da99fd
|
|
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
|
|
When a frame fails, disable all active planes for the display
and signal the release fences. This avoids the situation where
we might end up frozen b/c someone is waiting for the active
fences to signal.
BUG=chrome-os-partner:46301
TEST=Tested on smaug with a kernel that fails every 1000 frames
Change-Id: I3cd4ad4f22801068465b2c6278e96027b5a7e3c5
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Increase the acquire timeout to effectively 500ms before failing
a frame. Also log every 100ms so we're still able to track long
fence waits.
BUG=chrome-os-partner:46301
TEST=Tested on smaug with cts test, saw timeout messages, but not
failures
Change-Id: I28ec8bbf95f4a70bd3e99ea7a3333166c6080788
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
To accomodate peak usage situations.
Change-Id: I46031ce394abf1ec09177089508dd625d7c17aaa
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
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>
|
|
Instead of waiting forever for fences, set some reasonable timeouts
so we can move on with life if a fence doesn't signal.
BUG=chrome-os-partner:45868
TEST=Tested on smaug with osmos, recovered from fence timeouts
Change-Id: I7f18d684d483d789f228cbad8d5a3e43ac898a43
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
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>
|
|
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 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 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
|
