| Age | Commit message (Collapse) | Author |
|---|
|
This will allow NativeInputEventReceiver to subscribe to the frame
metrics notifications directly from the native code, without having to
involve java.
Java would still be needed to register the observer, though.
Bug: 376713684
Test: compile only, this infra is used in another CL
Flag: EXEMPT refactor
Change-Id: I7be8f0b2e94595f9a64ce69a22fe5910e0cd7711
|
|
Before this change, metrics were passed around as a raw array, without clear guidance of how big the array was or how to use it. The callers had to look into the implementation to understand that to use this array, "FrameInfo.h" needed to be included, and that the array size and indices were there.
With the current refactor, it will become slightly easier to use these metrics.
Bug: 376713684
Change-Id: Iecc04a0a215a7913ca8f49e4611fb104e1cacb8e
Test: compile only
Flag: EXEMPT refactor
|
|
The target work duration in HWUI ADPF is sometimes incorrect, and
is more often incorrect during buffer stuffing recovery due to the
exposure of new jank. The issue causes CPU clock frequencies to
decrease too much, and cause potential jank in subequent frames.
The original frame deadline should be used instead in calculating
the workload target deadline when triple buffered because even when
the deadline is pushed later during buffer stuffing, the throughput
requirements remain the same.
Also fixes a misordering in FrameInfoNames that was inconsistent
with FrameInfo and FrameMetrics.
Bug: b/389939827
Test: atest JankTracker
Test: presubmit, perfetto traces w/ and w/o buffer stuffing recovery
Flag: com.android.graphics.hwui.flags.calc_workload_orig_deadline
Change-Id: I2e3da6ee927d20fcbc9299ab5eda5732660d7246
|
|
.. so we could report the unintentional skipped frames to Perfetto,
rather than report undrawn frames as well.
Test: manual
Bug: 294884928
Change-Id: Ic49f4050cb3028d7adb5c930947ff6b72655d832
|
|
In the Vulkan pipeline, the GPU start time was measured to be when
swapBuffers starts. But the command queue has already been submitted at
this point, which means that the GPU work would already have begun. This
means that it's possible to measure a negative time since for very light
GPU workloads, the GPU fence can fire prior to CPU making it to
swapBuffers().
To compensate, instead measure from after skia completed submitting GPU
commands, until the GPU fence fires. Since it is theoretically possible
for GPU work to complete if the render thread gets descheduled
immediately after submitting the GPU, we also add some clamping to
ensure that the duration from command submission -> completion of GPU
work is nonnegative.
Bug: 230713131
Test: atest android.view.cts.FrameMetricsListenerTest
Change-Id: Ia30b7732eaab71e4e29766f788d5cd94ec63c38a
|
|
- Use GPU finish time as well as actual deadline to determine jank
rate.
- Use dynamic interval to adjust for 60/90hz switching
- Move frame metrics reporting into JankTracker to adjust the
deadline communicated to the app when in stuffing scenario.
- Adjust double-stuffing detection to be a bit more readable.
Test: GraphicsStatsValidationTest.java
Test: adb shell dumpsys gfxinfo
Test: FrameMetricsListenerTest
Test: Log output of FrameMetricsObserver
Bug: 169858044
Change-Id: I3a6b8ed163e2cf9cf2b67667110340ebe35f98a1
|
|
PerformanceHintManager.Session is in java, so add JNI and a HintSessionWrapper
class in HardwareRenderer. Then pass the two calls as two std::functions
into DrawFrameTask.
Note Session is created per HardwareRenderer, not global (per
RenderThread).
Session includes UI thread, render thread, and the thread pool.
Desired duration is from the intended start duration to the frame
deadline. Add an actual frame start time to compute
Add system properties:
debug.hwui.use_hint_manager to enable PerformanceHintManager
debug.hwui.target_cpu_time_percent to control percentage of frame time
to be used for target cpu duration.
Test: Manual test that there are no crashes and values make sense.
Bug: 158791282
Change-Id: I83f25433c10daa20033803fb7c4ae45eab34f1d3
|
|
Present time is available to apps, but is not currently stored inside
FrameInfo. In this CL, we add a location for storing the present time inside
FrameInfo.
Currently, the metrics reporter is triggered after the buffer is sent to
SurfaceFlinger. That means, metrics for anything that happens after gpu
draw completes are currently not available.
In a future CL, we will populate the 'presentTime' field.
In a future CL, we will register a metrics observer inside ViewRootImpl
in order to send this data to InputDispatcher. This will enable
end-to-end touch latency metrics collection.
Bug: 169866723
Test: printed present time inside FrameTimeline.cpp (surfaceflinger
side) and compared to the values printed inside a metrics observer
registered in ViewRootImpl (not done in this CL)
Test: atest ViewFrameInfoTest
Change-Id: I7d0f8c5d7b5a2572abdc4e107123e8938a36f582
|
|
Test: Provoke Davey, no crash
Bug: 171046219
Change-Id: Ife596b3ffe131ce201973417222a058ff7baec0f
|
|
- Add SurfaceStatsCallback to TransactionCompletedListener
- Register a callback in RenderProxy to be called when we have
surface stats from SF via the BLAST callback.
- Instead of finishing a frame for frame metrics reporting
immediately, wait until BLAST callback fires, note GPU completion
time and finish frame.
- Expose GPU_COMPLETION in FrameMetrics
- Modify TOTAL_DURATION to also include GPU_COMPLETION
Test: FrameMetricsListenerTest
Fixes: 171046219
Change-Id: I16fa1d80cfc4e7a5527c18fec7e885409f17ee4d
|
|
FrameInfo will now be per-window; that is, per-ViewRootImpl.
Some of the information should remain “global” (it remain in Choreographer),
while some information is going to become ViewRootImpl-specific.
Before the information gets passed to the native layer,
the ViewRootImpl-specific info will be stitched together
with the general Choreographer info.
This change is useful in order to correctly correlate frames with a specific
input event. In the unlikely scenario of a user touching two windows of the
same app simultaneously, this change will allow us to correctly measure the
latency of both frames produced by the windows.
Design doc: https://docs.google.com/document/d/1KMpMBlOxnl7zkWBCbXZZE6ZlaHEA4efYnN6WYK8n3FE/edit?resourcekey=0-eqooVNP0SskupljlTFvtOQ
Test: atest ViewFrameInfoTest
Bug: 169866723
Change-Id: Ib0bf9cd51cbcc0b9b70460c929c480eb490ec322
|
|
Pass the frame deadline calculated by SF to Choreographer so
hwui would be able to improve its stats by knowing if a frame is
likely to be late.
Bug: 169858174
Test: manual
Change-Id: Ib9fd93638b54f08d8dc72fa6b023e2dd7c276dc7
|
|
Add plumbing to get shared timeline data from Surface Flinger to HWUI
and back.
Bug: 162890382
Bug: 162888881
Bug: 162890407
Test: manual using ALOG messages in SF
Change-Id: I85c5eb56d2fa933889518854e7b79b1e65e29af3
|
|
Test: ran dumpsys with gfxinfo and graphicsstats
Change-Id: Id9950de87dc4343c6878baa6a6dd42fbc8aeddef
|
|
Test: No code changes, just ran through clang-format
Change-Id: Id23aa4ec7eebc0446fe3a30260f33e7fd455bb8c
|
|
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
|
|
Bug: 30440166
If we are using HWC2, there's a change in timing
when in triple buffering with the pipelined offsets.
This changes JankTracker to recognize that and silently
erase that from the total duration
Change-Id: Ib1fd4209070f17dbd2baed707c8cf73fb11c3cf2
|
|
Bug: 20853441
Calculating duration that crosses the UI-RT
sync point will now subtract out the time spent waiting
in queue under the assumption that this time will be
accounted for in the previous frame's metrics
Change-Id: Ia8213f4410638840613f5ae439e98dfb77532a6a
|
|
Bug: 21608208
Change-Id: I1d1cf1fbc8c0a4561bf76e307c56be580fb4baef
|
|
Bug: 21560187
Log column names as part of output in case of other such
issues
Change-Id: I16157ed968307e761d416ca54bd7af5453fe67bf
|
|
Is a bit naive, perhaps overly aggressive, but sorta works
Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
|