To make optimal performance/power consumption ratio we want to use composing by
dedicated hardware to merge as much as possible composition cases.
We are going to continuously optimize and improve drm_hwcomposer HAL, that
makes high demand on formal validation process.
Introduce "pixel operation" definition. It should be in direct ratio with power
consumption, but currently it roughly calculated as sum of pixels merged by
each layer.
In some future we should apply some average gains depending of operation type
to calculate pixops more precisely. (e.g. scaling should take more pixops than
blending, and blending should take more that copying, etc.).
Using pixops could be very helpful when drm_hwc HAL have a choice which layer
sets to merge by GPU, making possible minimal energy model based planning.
Create statistics of the following events:
- Total frames count
- Total pixel operations
- Pixel operations validated to use GPU (CLIENT)
- Calculate composer efficiency: DEVICE/TOTAL operations ratio
- Failed atomic validation commits count
- Failed atomic presenting commits count
Usage:
- $ adb shell dumpsys SurfaceFlinger
Statistics will be shown at the end of the dump in 2 forms:
- Since system launched
- Since last dumpsys command called
Using statistics for the regression slope monitoring example:
- Boot the board without the change
- Use touch or keyboard (avoid using of mouse pointer) to do some predefined actions (open application, start video, etc.)
- Save the metrics
- Boot the board with the change
- Do exactly the same actions as in (2)
- Save the metrics
- Use metrics before and after change to indicate regression slope
This code was used as reference:
https://android.googlesource.com/platform/hardware/interfaces/+/refs/tags/android-10.0.0_r11/graphics/composer/2.1/utils/hwc2on1adapter/HWC2On1Adapter.cpp#352
API is described in details here:
https://android.googlesource.com/platform/hardware/libhardware/+/refs/tags/android-cts-10.0_r2/include/hardware/hwcomposer2.h#1089