drm_hwcomposer: Implement BI and FB caching
This allows saving for about 2-6% of frame time spending in the HWC API
thread (value depends on CPU maturity).
Framework does not create a new buffer for every frame. Instead in 98%
of cases it sends the same buffers over and over (doing circular
shifting of the swapchain).
We can avoid redundant BufferInfo getting and FrameBuffer importing for
the whole layer.
To do this properly first we have to ensure we're having a deal with the
swapchain, not a set of unique buffers. This procedure internally called
the swap chain reassembling.
After we ensure CLIENT is using swapchain, we can safely store BI and
FB for every chain element and reuse it.
Example for single layer:
Frame # | Buffer Unique ID | State
-- | -- | --
1 | 301 | Reassembling...
2 | 302 | Reassembling...
3 | 303 | Reassembling...
4 | 301 | Caching... (Chain reassembled!)
5 | 302 | Caching...
6 | 303 | Caching...
7 | 301 | Reusing cached data
8 | 302 | Reusing cached data
9 | 303 | Reusing cached data
... | ... | ...................
999 | 304 | Not in cache, purge the cache.
1000 | 305 | Reassembling...
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
diff --git a/hwc2_device/HwcDisplay.cpp b/hwc2_device/HwcDisplay.cpp
index 02df28c..76e2745 100644
--- a/hwc2_device/HwcDisplay.cpp
+++ b/hwc2_device/HwcDisplay.cpp
@@ -602,6 +602,7 @@
* https://cs.android.com/android/platform/superproject/+/master:hardware/interfaces/graphics/composer/2.1/utils/hal/include/composer-hal/2.1/ComposerClient.h;l=350;drc=944b68180b008456ed2eb4d4d329e33b19bd5166
*/
if (target == nullptr) {
+ client_layer_.SwChainClearCache();
return HWC2::Error::None;
}