cros, gbm: scale a overlay plane by native scaler, instead of VPP
Currently, for Intel, VPP (video processing hardware)[1] scales a overlay plane,
instead of display controller [2].
[1] https://software.intel.com/en-us/node/628415
[2] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
VPP scaler was introduced to support hardware overlay for old Intel SoCs.
However VPP scaling doesn't make sense because it consumes more bandwidth
(results in power) than GPU compositing. VPP needs to read the given buffer and
then write to new temp buffer. It already consumes similar bandwidth to GPU
compositing, but hardware overlay path still needs to send the overlay plane
to display controller. This CL removes this incorrect legacy, and make
scaling rely on the native scaler which atomic modeset API natively supports,
which finally display controller scales the plane by itself. For Intel, Skylake
or newer SoCs support it. [2]
In the code side, only Intel sets OverlayPlane::ProcessBufferCallback,
which points out VPP scaler.
HardwareDisplayPlaneManager already uses native scaler (i.e. display controller
scaler) via |crtc_w| and |crtc_h| value on drmModeAtomicAddProperty() call,
only if OverlayPlane::ProcessBufferCallback isn't set.
ARM and Rockchip don't set the callback and rely on native scaler already. cc
checks if display controller can support scale via OverlayCandidateValidator.
If not, cc composites the layer by GPU.
BUG=683347
TEST=run https://www.quirksmode.org/html5/tests/video.html on reef and eve
using cros kernel intel-graphics/syncfence_ams_npf_mst_607_r2 branch
Change-Id: Id492c0317313fe6a905ee96797ceefbb9746d798
Reviewed-on: https://chromium-review.googlesource.com/544617
Commit-Queue: Dongseong Hwang <dongseong.hwang@intel.com>
Reviewed-by: Daniel Nicoara <dnicoara@chromium.org>
Reviewed-by: Dongseong Hwang <dongseong.hwang@intel.com>
Cr-Commit-Position: refs/heads/master@{#483086}5 files changed
