1. 04 Dec, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Introduce dumpsys metrics · 0d1a2cdb
      Roman Stratiienko authored
      
      
      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:
      1. Total frames count
      2. Total pixel operations
      3. Pixel operations validated to use GPU (CLIENT)
      4. Calculate composer efficiency: DEVICE/TOTAL operations ratio
      5. Failed atomic validation commits count
      6. Failed atomic presenting commits count
      
      Usage:
       - $ adb shell dumpsys SurfaceFlinger
      Statistics will be shown at the end of the dump in 2 forms:
      1. Since system launched
      2. Since last dumpsys command called
      
      Using statistics for the regression slope monitoring example:
      1. Boot the board without the change
      2. Use touch or keyboard (avoid using of mouse pointer) to do some predefined
      actions (open application, start video, etc.)
      3. Save the metrics
      4. Boot the board with the change
      5. Do exactly the same actions as in (2)
      6. Save the metrics
      7. Use metrics before and after change to indicate regression slope
      
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
      0d1a2cdb
  2. 03 Dec, 2019 1 commit
    • Matteo Franchin's avatar
      drm_hwcomposer: Fix returned fence in PresentDisplay · c56eede3
      Matteo Franchin authored and John Stultz's avatar John Stultz committed
      
      
      DrmHwcTwo::HwcDisplay::PresentDisplay was always returning -1 as the
      present fence. This commits ensures the fence fd is correctly retrieved
      after doing the commit-frame operation. It also updates outdated logic
      that caused PresentDisplay to return the retire fence rather than the
      present fence.
      
      DrmHwcTwo::HwcDisplay::AddFenceToPresentFence is also changed so that
      it assumes it is given ownership of the file descriptor it receives as
      argument. This function was indeed called consistently with this
      behaviour, which meant the dup led to leakage of file descriptors.
      
      With the changes above this patch fixes a failure in the CTS test
      dEQP-VK.wsi.android.display_timing.fifo.display_timing (for example
      running Android 10 on HiKey960). The test failed with the error
      "Unexpectedly received invalid timestamp." reported multiple times in
      the logcat output.
      
      Change-Id: If662e5239895b8b0e2ea31fd99747855f901a427
      Signed-off-by: Matteo Franchin's avatarMatteo Franchin <matteo.franchin@arm.com>
      c56eede3
  3. 28 Nov, 2019 2 commits
  4. 27 Nov, 2019 1 commit
  5. 21 Nov, 2019 3 commits
  6. 20 Nov, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Fix mixed layer composition · f2647231
      Roman Stratiienko authored
      
      
      Fix cases when mixed layer composition require non-device layer in the middle:
      
      '''
      Layer z_order - SF type    - validated type before - validated type fixed
                  0 - DEVICE     - CLIENT                - CLIENT
                  1 - DEVICE     - DEVICE                - CLIENT
                  2 - DEVICE     - DEVICE                - CLIENT
                  3 - SOLIDCOLOR - CLIENT                - CLIENT
                  4 - DEVICE     - DEVICE                - DEVICE
      '''
      
      In such composition SF will merge layers 0 and 3 and hwcomposer will
      merge <SF>,1,2,4 that results incorrect merging order.
      
      Issue was observed on the rcar3 (imagination importer), db845c and allwinner H3
      (Generic importer) platforms.
      Reproduces with compositions that requires 'cursor' or 'dim' layers.
      How to reproduce:
       1. Connect USB mouse when on home screen, you should see mouse cursor
          under icons (Tested with Launcher3QuickStep desktop)
       2. Go to Settings -> WIFI -> Connect to the AP, then you should see
          password dialog under AP list.
      
      Solution:
      1. Mark intermediate layers as CLIENT to ensure CLIENT section is in range
      from bottom layer to most top CLIENT layer.
      
      2. Use this layer composition to validate if DRM can handle it.
      
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
      f2647231
  7. 11 Nov, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Add Imagination platform support · e3ed48d7
      Roman Stratiienko authored
      
      
      External Android.bp file should be created in order to build this module:
      ```
      cc_library_shared {
          name: "hwcomposer.drm_imagination",
          defaults: ["hwcomposer.drm_defaults"],
          srcs: [":drm_hwcomposer_platformimagination"],
          whole_static_libs: ["drm_hwcomposer"],
          shared_libs: ["libion"],
          include_dirs: [
              "path/to/imgtec/include/files",
          ],
      }
      ```
      libion is needed to make ion.h header visible `linux/ion.h`.
      
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
      e3ed48d7
  8. 06 Nov, 2019 1 commit
  9. 22 Oct, 2019 4 commits
  10. 10 Oct, 2019 1 commit
  11. 11 Jul, 2019 2 commits
  12. 21 Jun, 2019 1 commit
    • Neil Armstrong's avatar
      drm_hwcomposer: pre-filter modes provided to HWC2 · b67d049c
      Neil Armstrong authored
      
      
      Currently LocalDisplayAdapter in AOSP filters out similar modes based
      on their currently limited supported attributes: width/height/refresh.
      
      This leads to a situation where important modes are discarded, like the
      preferred mode and/or the active mode, leading SurfaceFlinger to select
      an unwanted and potentially invalid  mode in the list provided by
      drm-hwcomposer to HWC2.
      
      Let's pre-filter the modes provided to HWC2 by :
      - systematically adding the preferred mode
      - systematically adding the current active mode, if different
        from preferred mode
      - keeping the interlaced modes filtering-out if no other non-interlace
        modes with same widthXheight exists (for HD-Ready 1080i TVs or CVBS)
      - discarding modes if a similar mode with same widthXheight@refresh was
        already selected for HWC2
      
      This mimics the behavior of LocalDisplayAdapter filtering algorithm,
      but keeps the important modes from the DRM Point Of View and drops the
      duplicate modes while keeping the mode ordering from DRM in account.
      
      This local filtering should ultimately go out when HWC2 can actually
      handle mode Attributes to describe Preferred mode, Interlaced, 3D...
      and LocalDisplayAdapter uses these Attributes for filtering duplicate
      modes.
      
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Tested-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      b67d049c
  13. 11 Jun, 2019 3 commits
  14. 07 Jun, 2019 1 commit
  15. 04 Jun, 2019 1 commit
  16. 11 Apr, 2019 1 commit
  17. 10 Apr, 2019 2 commits
  18. 30 Mar, 2019 1 commit
  19. 28 Mar, 2019 1 commit
    • John Stultz's avatar
      drm_hwcomposer: Tweak mode selection to pick the first DRM_MODE_TYPE_PREFERRED mode · a3429c7a
      John Stultz authored
      With commit 1b1e35eb
      
       ("drm_hwcomposer: Chose preferred mode with
      type DRM_MODE_TYPE_PREFERRED"), we now pick a preferred mode
      rather then just the first mode to use.
      
      However, on some systems there may erroniously be multiple modes
      marked as DRM_MODE_TYPE_PREFERRED. In this case, the logic added
      in that commit ends up selecting the *last* preferred mode.
      
      This seems less likely to be the desired choice, compared to
      what we had before (which picked first mode provided).
      
      So this patch alters the selection logic to only use the first
      DRM_MODE_TYPE_PREFERRED mode found, rather than the last.
      
      Change-Id: Ieb3e5d946b96099f14c1c5a287ca8113360a39d1
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      a3429c7a
  20. 19 Mar, 2019 1 commit
  21. 18 Mar, 2019 3 commits
  22. 15 Mar, 2019 1 commit
  23. 06 Mar, 2019 3 commits
  24. 05 Mar, 2019 1 commit
  25. 28 Feb, 2019 2 commits
    • John Stultz's avatar
      drm_hwcomposer: Initialize buffer_ pointer to NULL · 6230703e
      John Stultz authored
      
      
      In some cases, we've seen drm_hwcomposer start to try to
      compose frames before anything has called SetClientTarget().
      
      This seems to be some sort of a race, which for some reason
      we only see with certain dummy HDMI dongles (which provide
      fake EDID data) which allow our lab machines to run headless.
      I'm still trying to understand more about why this happens
      only in this case.
      
      The net of the issue is we see CreateComposition() being called,
      which adds the client_layer_ to the zmap. Then it creates the
      DrmHwcLayers copying the non-initialized buffer_ value as the
      sf_handle.
      
      This then later causes a crash in ImportBuffer() when we
      traverse the non-null (but invalid) hnd value.
      
      Thus, this patch simply initilizes the buffer_ pointer to NULL
      so that we error out properly in the case of the race.
      
      Reported-by: Yongqin Liu's avatarYongQin Liu <yongqin.liu@linaro.org>
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      Change-Id: I5fde3fccde86519edb04e61cbc2842eda395ade4
      6230703e
    • John Stultz's avatar
      drm_hwcomposer: platformhisi: Conditionalize some of the AFBC support · 65c988de
      John Stultz authored
      
      
      Unfortunately with the AFBC support patches, I validated with
      the hikey960 (which has a gralloc that supports AFBC), but not
      with the original hikey board (which does not support AFBC).
      
      Since we use the same importer for both boards, conditionalize
      the AFBC logic if those values are not defined.
      
      This patch will also need a tweak to the hikey gralloc to add
      support for the handle->internal_format reference (which doesn't
      currently exist on hikey's gralloc).
      
      Change-Id: I31aea82b321ff7dd7608c6a3522cbc93bb629319
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      65c988de