Currently, it is possible to notify frame metrics observers that
registered to receive present time about the same frame twice.
This is wasteful, but also requires the metrics listener to guard
against duplicates. See https://b.corp.google.com/issues/169866723#comment23
To avoid this issue, only notify about metrics with present time just
before the frame is advanced to the next position. This ensures that we
are always notifying about the last frame that's about to go away.
Bug: 169866723
Test: added a crash to LatencyTracker for the case where we are notified
about non-existent record. The record disappears once it's complete. So
the first call was completing the record, and the second call was
causing a crash. Now, the crash is gone with this patch.
Change-Id: Ia247b4a0010b8ecb016ac66e44e211ec4f40bf8f
To measure end-to-end touch latency, we need to report the actual
present time to ViewRootImpl. ViewRootImpl, in turn, will report this
information to InputDispatcher. Finally, InputDispatcher will combine
all known information for a specific input event, and will report this
data to westworld.
In another patch, we will add a new call, 'reportLatencyInfo', to
InputPublisher. This call will allow the app to send this latency data
to InputDispatcher.
Bug: 169866723
Test: printed the input event present times inside ViewRootImpl
Change-Id: Ibd3a2cfeb1a340eb15cd2165071df1f8589634af
Previously we would submit a command buffer for the
frames draws and then immediately submit a second
command buffer that had no commands and just an attached
semaphore. This merges those two submit calls into Skia
into one call.
Test: manual running of system of benches
Bug: 175913056
Change-Id: If0d054960de8b459814cbfa9289756f8ee9d4a93
(cherry picked from commit f16ba60194)
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
- 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
add a method, setSurfaceControl, for java layer to pass surface control to the render thread
Bug: 173671170
Test: call setSurfaceControl method in ViewRootImpl.java
Change-Id: I886a79c377938f19cf38b9058f2bec64e1439000
The flush and submit at the start of trim memory now syncs the
cpu so that all work is done on the gpu and the max possible
amount of resources can be freed
This fixes CacheManager unit test since the submit at the end
trim memory was causing new resources to be available to be
purged.
Test: locally ran unit tests
Bug: 178978639
Change-Id: I8b57b042dd146fc6c1083540715295e93fd113d3
(cherry picked from commit 846644a46e)
As HWUI uses vsync id to send buffers to SF, SF applies the right
amount of render ahead by latching the buffers at the configured time.
Test: launch an app and observe systrace
Bug: 178148035
Change-Id: Ifd3e1a2971aad0a085cb35d33e950194046aa634
0 and -1 both meant default when 0 should mean
0 and -1 should mean default
Test: manual
Fixes: 179290765
Change-Id: Ia9aa5e3d83757282bfff776e083d6b3d7d29e9c0
The application receives input events and produces graphic buffers in
response. We are interested in measuring the total time that the input
event takes to process, from the moment it's received on the device, to
the moment that the image is displayed on the screen.
To do this, we need to understand which input event produced a specific
buffer. In this CL, we are sending the input event id from FrameInfo to
SurfaceFlinger. This event id will later be used to identify a specific
frame, and provide the frame timing information to inputflinger.
Inputflinger will be able to use this information to reconstruct the
complete event timeline, and record metrics on the duration of each
input / graphics processing stage. This will allow us to optimize
end-to-end touch latency.
In the current CL, we are using 'NewestInputEvent' as the inputEventId.
That's not quite correct. Today, this field contains the timestamp of
the input event. Therefore, we will simply pass the truncated
timestamp instead of proper input event id. We will fix this in a
separate CL by providing input event id to FrameInfo.
Design doc: https://docs.google.com/document/d/1G3bLaZYSmbe6AKcL-6ZChvrw_B_LXEz29Z6Ed9QoYXY/edit#
Bug: 169866723
Test: printed input event id at the site of SurfaceFrame creation in
FrameTimeline.cpp
Change-Id: Ia90337bb2f000e9c93a4db04d9dd6ea9ea153520
* Degrade error when changing the rendering backend from Properties to
no longer be fatal.
* Support using a single graphics queue for the Vulkan backend. Cloud
devices only support a single queue and some Vulkan implementations such
as Swiftshader expose only one queue for simplying their implementation,
so we'll need to support one.
Bug: 175618060
Bug: 162628999
Test: hwui_unit_tests
Test: experiment on Pixel 4 enforcing a single queue (settings app,
maps, sysui)
Change-Id: I495fcabc3c89bd62bbb833998eab4944c6660f6f
Vulkan context is shared with HardwareBitmapUploader and the
RenderThread, meaning if the upload thread runs prior to the render
thread then some configuration is skipped such as recording the max
texture size and cache setup, which affects benchmark tools. So we need
to check whether the GrContext exists in addition to checking if the
shared VkManager has been properly intialized.
Bug: 175913056
Test: hwuimacro works for benchmarks that upload HW bitmaps prior to
benchmark execution. For example: tvapp_norcEglImage
Change-Id: I149c294b39f1e88226fc5d8d72c30bc4fb3d8404
If returning early from a draw, there is a chance that the frame
complete callbacks can execute before the frame callbacks. To fix
this, explicitly wait on frame callbacks to complete.
Test: Enable blast and test split screen resize
Change-Id: Id0eabd4dacdccbf1ce774efaad51abae7c57d5ea
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
The logic in setBufferCount was still assuming it needed
to inject the extra buffers, however that injection was
already happening in the min_undequeued query. So it was
increasing buffercount by 2x the extraCount, or concretely
5 buffers when it should have been 4 on >75hz devices
Bug: 168928692
Test: Boot coral, verify 4 buffers instead of 5
Change-Id: I0908228a6791d90544fbf4cb21170931bd31a9db
This is part of API cleanup as we make DDL usage more mainstream
in Skia. Since Android doesn't use DDLs, the cast from recordingContext
to directContext will always succeed and there's no functional change.
Change-Id: Ie585cf6c97d01fecf082f146d5692999371fd39d
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
The difference between recording & direct contexts does not matter
to Android right now because they don't use DDLs, so there's no
functional change here.
Change-Id: Iedcdf5c3ce0ccd3c7e1724d8fb45b7882d8c2129
This change also fixed that the graphics queue should be the one to wait
on upon surface destruction.
Bug: 162628999
Bug: 167693610
Test: no new regressions in CtsUiRenderingTestCases with Vulkan backend
Change-Id: I919748b85b2194bb4f13e1af6950d6493a17921d
The VkInstance and VkDevice are constructs that can be shared between
threads and avoid the extra driver allocations associated with them.
This CL also fixes a bug where Vulkan uploads were occuring on the
thread that invoked the upload and not occuring on the upload thread.
Bug: b/162628999
Test: atest CtsUiRenderingTestCases
Change-Id: I0289938333e2c3dafcc2ce18e72dca3acf4d5b79
The original CL is not needed as HardwareRenderer.preload is not in Zygote but at app launch time.
Bug: 162242036
Change-Id: I41e46e22cb9730b350feb9f6acb2021264a18a97
Test: atest CtsUiRenderingTestCases all pass on GL backend
Test: atest CtsUiRenderingTestCases no regression on VK backend
Creating GPU context besides loading the GPU driver would potentially
affect graphics driver updatability. Currently, we always preload
graphics drivers in Zygote to speed up app startup time. Upon using
updatable driver, we'll unload the current driver and load the uploaded
one. Although the symbol table is fully protected by the linkerconfig we
setup in Android 10, we still have to make sure the driver has a clean
state upon unloading and reloading.
At this moment, Vulkan driver unloading has not been supported yet. So
if we are going to turn on skia Vulkan backend by default, we should
avoid preloading the Vulkan driver until the unloading feature is
supported for Vulkan.
Bug: 162242036
Bug: 135536511
Test: atest CtsUiRenderingTestCases all pass on GL backend
Test: atest CtsUiRenderingTestCases no regression on VK backend
Change-Id: I9084586315a7593be2cfe17710620aacce568d36
This is part of an effort to distinguish between different types of
contexts in GPU Skia. When using a DeferredDisplayList (DDL)
recorder, the context you get is not a direct context and cannot
be used for operations like uploading or reading textures.
Since Android does not use DDLs, it is not directly affected by this
change but other APIs, such as SkImage::MakeFromTexture are
being migrated to require a GrDirectContext to increase sanity.
Change-Id: I9afbdf3c026a9f9cb6ad2aad904915e189e584d6
When we moved off of gui/SyncFeatures for retrieving this extension, we
accidentally didn't include the eglQueryStringImplementationANDROID path
for retrieving extensions. Fortunately this extension is only used for
TextureView synchronization, but we should still use the extension when
available.
Bug: 159921224
Test: Manually inject log statements to verify the extension is
correctly visible.
Change-Id: Idaa872778afc13e86bdea918da8631b4747fe9c1
Bug: 155002050
Test: Manual - scroll Pchome app
This reverts commit 05ac516412.
Reason for revert: When running Pchome, this change resulted in poor
performance while scrolling. Every frame appears to be uploading
several textures, potentially the same textures over and over again.
Change-Id: I0fc7216e16f783051d1bd87af764c1a6f361c138
