If there is a GEOMETRY change try the load based compositions first
and then cache based. Vice versa otherwise.
Change-Id: Ie7ce6017e867f47e975487a72fba81f5d94eb9e3
Earlier, on configuration errors, we simply drained the fences held
by current rotator objects and went to GPU comp. The rotator objects
were deleted in the subsequent rounds, if they remained unused.
If we don't use GPU comp on failure but use other strategies, then we
need to mark the rotator objects for a display for reuse, so that
other strategies can use them.
Also any failure resets on overlay or rotator need to happen from
functions that call configuration helpers rather than the helper
themselves. Leaving cleanup to black-box helpers is not desirable.
Change-Id: I59b5b1bb774b82ee85a037e934c9d2d023db30af
Fall back to GPU for one cycle at the start of animation and display
the frame buffer for the subsequent cycle till animation ends.
Change-Id: I6c651cebaf4694f326d6e32ae485e014f391577c
Combine the redundant code for FB programming and source split
adjustment into appropriate functions.
Change-Id: Ib99a2297a672e5ef40acb9f246021e57e41cd759
Reset the updating layer count when new batch is started.
Else this will effect framebuffer z-order.
Change-Id: If746a5ea4b482cd7b55ba95007a3b8d7f1dc9b6e
CRs-fixed: 584021
Add hw limitation checks for MDP composition once
we identify actual layers for MDP. This should be generic
way for all basic hw limitations of underlying MDP/MDSS.
Current limitations:
- a-family : MDP can not handle alpha scaling.
- 8226 & 8974 : Can not handle if multiple layers need
downscaling and blending
Change-Id: Ia944802d798f2d0e9cd4515d7e9854c7314cac78
CRs-fixed: 538803
The programYUV used for video-only cases is the same as programMDP
function. Remove the redundant function
Change-Id: I1d891404a77b2a47f90c236d4d6dcbbd02143d93
For 8x26, if there is only one layer which needs scale for
secondary display, while no scale for primary display, DMA
pipe is occupied by primary. If layer changed and need to
fall back to GLES composition, virtual display lacks DMA
pipe and error is reported.
To avoid this case, use GPU composition for virtual display
scaling case on 8x26.
Change-Id: I42297a18006517532e30d1a01c67ff8ca187482a
Use the low and high bandwidth values exported from driver per target
Use the low bandwidth value when the system has at least 1 video
mode panel, else use the high bandwidth value.
Newer targets could have bandwidth exceeding what an uint32 could
hold, so change the bytes read to be in gigs.
Do not use the framebuffer handle to get size, since the handle may
be null.
Change-Id: If3124ddc33334eba80d34ab7d8fc64d1b46697ce
Check for downscale support only for layers which needs to
be downscaled. Fixes issue where we bail out for all layers having
width more than MAX_LAYER_WIDTH even when they don't need scaling.
Change-Id: I19ee4d69e986390ed3df122b8ca9c0e102f3f916
To minimize usage of decimation when 4K x 2K video is played
on primary, split the yuv layer into 2 halves and configure
each layer to individual VG pipes. With this approach,
decimation can be avoided in some 4K x 2K video use cases,
thereby improving performance.
Change-Id: I7cddfab787c50f6ff132eaa7f5a3d9cfd636c282
GPU's perf is proportional to the number of pixels it processes, so
the load based strategy that prefers GPU, attempts to load it less
in terms of pixels, and at the same time makes sure the MDP has
enough pipes and mixer stages.
MDP's perf is real time and proportional to the instantaneous b/w
which is a function of overlaps. So the load based strategy that
prefers MDP would look at sending only as many full-screen layers
that MDP could support.
This mode is used when the GPU-preferred mode fails.
Change-Id: I3221a94bb01c43112370c248cd4ab217f2bd8ed1
Bytes claimed doesn't reflect the panel refresh rate.
So use the bandwidth claimed instead which factors this in.
This is important when 2 displays are running at different
refresh rates.
Change-Id: I3ab9573e43b8c25c31e01888fb2b181469b9e91b
1. Color layer has a destination rectangle, RGBA color and plane
alpha. There is no gralloc buffer. Layer flag "HWC_COLOR_FILL"
denotes a Color layer.
2. There is no color member in HWC layer, so RGBA color value
is passed via the "tranform" member from framework to HAL.
Change-Id: I8769fd3f5febcaf952a1456de0a4262679c9a0e4
Move resource checks, pipes, stages of mixer, bandwidth to a common
function and use it from all strategies.
Change-Id: I161fc957e2793d543b5943fbd23ae3607a4cfc87
Instead of trimming out of screen layer dimensions for various
operations repetitively, trim and store.
Will also prevent accidentally missing out on trimming.
Change-Id: I8800586070ec433aa1fcbb3aad73ec29c9c9111e
When MDP cannot handle an updating layer and we marked it for GPU,
make sure framebuffer is refreshed for that frame. In the current design,
only video layers fall into these catches. But we may need
this change for future composition strategies.
Change-Id: I1d6a92da13feef4b353fa5e196d42f91148412e5
CRs-Fixed: 575340
- Iterate layer list to drop layers from composition that
are not going to be visible inside the updating ROI.
- No ROI when skip layers are present.
- Reset dropped layer info on full GPU fallback.
Change-Id: Ib544526a8c28ffdd16b5be12f73d57d10d207c39
When we try MDP composition only for secure layers, bail out if
secure layers are not present. Otherwise partial MDP composition
succeeds with all layers marked for FRAMEBUFFER.
Change-Id: I3f968835951320bb6c5873ba77fedef8a359b7bf
- Always use sourceCropF instead of sourceCrop.
- Change it to sourceCropF at places where sourceCrop
used
Change-Id: Ia64050a41a174f3f038c9b88d527d70c2240f2d9
GPU cannot handle secure layers so a black screen is seen when we
punt secure layers with non integral source crops.
Bug:11156948
Change-Id: Ie19c631aab55dc8e7c1ad5e1f42162e833f49222
The MDP driver cannot handle such layers right now. Investigate
doing this with pixel phase in the future.
Change-Id: Iabbdd0285234160770ae5a799b07a5b912e5fde3
(cherry picked from commit e6aff6414ba478312d9d4af21ab63d586594009f)
Increment hwc version to 1.3.
Create and use a converter from float source crop to integers.
Change-Id: I5e185195c975b3a9434c5d9dce9ae4757ff98739
(cherry picked from commit 7e5637c850bcdbe21784ca3bfa9668870306adff)
Redraw the cache if current frame cache/drop data doesn't
match with cached frame data. Frame buffer z-order, fbcount
and mdp count are not reliable. With same fbz, fbcount and
mdpcount it is possible that layers in previous cached
frame are not part of current frame fb cache.
Change-Id: I858228dc1a3a8ab8673ab8d294e54fdbf43cc1ad
Add support for load based partial mdp comp.
This is used on geometry changes where a redraw is unavoidable.
We select a batch of layers, that has minimum pixels for FB comp,
the rest go to MDP.
Conflicts:
libhwcomposer/hwc_utils.cpp
libhwcomposer/hwc_utils.h
Change-Id: Ifc5eeb4785c75c37de97a2bb89ca81409d324691
While marking layers for cache, neglect the z-order when
possible, to improve the scope of mixed mode usage.
It is safe to neglect the z-order if a static layer
doesn't have any overlapping region with updating layers
in between static layer & contiguous static layers batch.
- if above layer doesn't have any overlapping with updating
layer in middle, push it to the batch.
- If above case fails, but layers below(existing batch) does not
have any overlapping region with the updating layer, bring the
batch to top and modify fb-zorder accordingly.
Change-Id: I4882a750d0a9a2e11272fcbb146202160673d04f
- Identify secure display layer in the hwc_list
- Need to set both SECURE_OVERLAY and SECURE_DISPLAY flags for the secure
display layer
- Disable idle timeout for secure display usecase, as GPU should not be
accessing secure display layer
Change-Id: I555910db77c466b5e103b24b4f0ec7f47bb210a5
This change adds support in HWC for MDP partial update applicable
only for command mode panels. Presence of MDP FB (GRAM) in
command mode panels allows MDP clients to update only the updating region
of the frame as rest of the frame will be cached in the GRAM.
HWC calculates the updating region of a frame (ROI) by deducing
outer bounds of its updating layer destinations. Layers not lying
within the calculated ROI will be dropped from the composition
since its illegal to program MDP pipes for non participating layers.
Change-Id: I890d98ff7960fe888787981803cac62f68471201
In prepare, we check if MDP can handle the number of layers
given to it. If it cannot, we fall-back. Additionally, we must
not proceed with any MDP bytes calculations otherwise we will
see out of bounds errors.
Change-Id: Ifae45aefbc8732a7f21f5652758ece3a7639be9a
When MDP cannot support a layer, we send the whole list of layers to
GPU. If such layers are not updating they can be cached on FB while
allowing the rest to take the MDP route.
Example # 1: Volume bar on video in 90 rotated mode. Since volume bar
is not h/w accelerated, there is no prerotation and we invoke the GPU
for redraws each round. With this change we won't because of caching.
Example # 2: If prerotation is applied to layers on primary, the
secondary layers would show a transform and the whole list is redrawn
with GPU. Now we could make use of caching.
This change also imposes a 1 layer limit on secondary, but now allows
full and partial MDP comp, thus benefiting secondary-only content.
Change-Id: I7eb43ba817f1081f317fefa99fa0c507344060e8
The ab (average bandwidth) is just the average and there could be
underruns when ib (instantaneous bandwidth) is attempted to be used.
Add additional factor to use ib instead of ab. This means we need to
assume that all the layer contents could be requested together, rather
than one after another.
Also use the trimmed layer dimensions for calculations.
Change-Id: I771f964e1c80b5db564faa01cdfb75d75b54f97a
In video handling this patch makes sure:
1) Sufficient VG pipes are available, not just any pipes
2) If VG pipes are insufficient in multi-video scenarios
preference is given to secure videos
Change-Id: I170592463a1c28348108a1b12d60908cf3063d7d
When checking for pipes needed for each mixer, the pipes completely
unused are counted twice.
Add a per display check on top of per mixer check to make sure this
is taken care of.
For example: Each mixer needs 4 pipes, and total completely unused
pipes are 6. Each mixer will get 6 as available pipes, which is ok
at a mixer level, but at a display level 8 pipes are needed and 6
available. Need to account for that
Change-Id: I9811255aab96c7fe47331f8aa125fef2a4a2f704
