ozone: prefer YUYV format for overlay.

ozone: prefer YUYV format for overlay.

Mesa doesn't support EGL image for UYUV format.
It's why crrev.com/2689453002 introduced YUYV format.
As YUYV is only format supported by all linux stack such as kernel, mesa,
minigbm, and gpu decoder, ozone prefers YUYV format for overlay.

BUG=683347
TEST=ozone_unittests
run chrome on http://www.quirksmode.org/html5/tests/video.html with --enable-hardware-overlays

[inactive_dshwang_plz_cc_intel, 2017-02-09 04:43:58]

The CQ bit was checked by dongseong.hwang@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-09 04:44:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dshwang, 2017-02-09 04:44:38]

dongseong.hwang@intel.com changed reviewers:
+ dcastagna@chromium.org, spang@chromium.org

[dshwang, 2017-02-09 04:44:39]

dcastagna@, as you reviewed in https://codereview.chromium.org/2648633005/, this
part is extracted.

spang@, could you review?

[commit-bot: I haz the power, 2017-02-09 05:17:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-09 05:17:35]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[spang, 2017-02-27 22:38:16]

lgtm

[Daniele Castagna, 2017-02-27 23:10:55]

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
File ui/ozone/platform/drm/gpu/drm_overlay_validator.cc (right):

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:66: uint32_t
FindOptimalBufferFormat(uint32_t original_format,
Is any device actually using this code path?
I think this code is exercised only in unit tests.

IIUC this was intended to be used for a late buffer conversion just before page
flipping.
DS, you told me we didn't want this anymore, right?

[dshwang, 2017-02-28 02:14:28]

thank you for reviewing

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
File ui/ozone/platform/drm/gpu/drm_overlay_validator.cc (right):

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:66: uint32_t
FindOptimalBufferFormat(uint32_t original_format,
On 2017/02/27 23:10:55, Daniele Castagna wrote:
> Is any device actually using this code path?
> I think this code is exercised only in unit tests.

This code is used by both legacy page flip and nuclear page flip. see
DrmOverlayValidator::TestPageFlip()

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:151: window_->bounds(),
controller);
> IIUC this was intended to be used for a late buffer conversion just before
page
> flipping.
> DS, you told me we didn't want this anymore, right?

When display size and video size are different, we need late buffer conversion.
The format conversion happens only if size conversion is needed.

Note: I'll add native scaler support soon, which scaling by display controller.
After that, this code path will remain for only legacy page flip.

[dshwang, 2017-02-28 02:14:42]

The CQ bit was checked by dongseong.hwang@intel.com

[commit-bot: I haz the power, 2017-02-28 02:15:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 02:40:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-28 02:40:30]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Daniele Castagna, 2017-02-28 02:56:08]

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
File ui/ozone/platform/drm/gpu/drm_overlay_validator.cc (right):

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:66: uint32_t
FindOptimalBufferFormat(uint32_t original_format,
On 2017/02/28 at 02:14:28, dshwang wrote:
> On 2017/02/27 23:10:55, Daniele Castagna wrote:
> > Is any device actually using this code path?
> > I think this code is exercised only in unit tests.
> 
> This code is used by both legacy page flip and nuclear page flip. see
DrmOverlayValidator::TestPageFlip()

We're not using overlays on Intel ATM. So, this is not exercised, please correct
me if I'm wrong.

Doesn't Intel Kaby Lake support scaling on primary plane? Why do we need some
special code with a late conversion?

[dshwang, 2017-02-28 04:01:59]

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
File ui/ozone/platform/drm/gpu/drm_overlay_validator.cc (right):

https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:66: uint32_t
FindOptimalBufferFormat(uint32_t original_format,
On 2017/02/28 02:56:08, Daniele Castagna wrote:
> On 2017/02/28 at 02:14:28, dshwang wrote:
> > On 2017/02/27 23:10:55, Daniele Castagna wrote:
> > > Is any device actually using this code path?
> > > I think this code is exercised only in unit tests.
> > 
> > This code is used by both legacy page flip and nuclear page flip. see
> DrmOverlayValidator::TestPageFlip()
> 
> We're not using overlays on Intel ATM. So, this is not exercised, please
correct
> me if I'm wrong.

Correct. production code never use it.

To test this code by chrome, additional commend line is needed
 * atomic mode setting: --enable-hardware-overlays --enable-drm-atomic
 * legacy mode setting: --enable-hardware-overlays

> Doesn't Intel Kaby Lake support scaling on primary plane? Why do we need some
> special code with a late conversion?

Yes, Kaby Lake and ApolloLake support scaling on primary plane on upstream
kernel. Intel integration team is cherry-picking relevant patches to chromeos
v4.4. As nuclear page flip is available on (near-future) v4.4, we will enable it
from ApolloLake and Kaby Lake. Skylake can support it by hardware tho.

Current code includes many experiments. If we want to remain only production
code for ApolloLake or newer, FindOptimalBufferFormat() as well as the special
code can be removed.

By the way, could you share ARM chromeos status? ARM can support native scaling
and doesn't need this code?

[dshwang, 2017-02-28 04:03:31]

ah, it depends on https://codereview.chromium.org/2689453002/
let me wait.

[Daniele Castagna, 2017-02-28 04:06:38]

On 2017/02/28 at 04:01:59, dongseong.hwang wrote:
>
https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
> File ui/ozone/platform/drm/gpu/drm_overlay_validator.cc (right):
> 
>
https://codereview.chromium.org/2686903003/diff/1/ui/ozone/platform/drm/gpu/d...
> ui/ozone/platform/drm/gpu/drm_overlay_validator.cc:66: uint32_t
FindOptimalBufferFormat(uint32_t original_format,
> On 2017/02/28 02:56:08, Daniele Castagna wrote:
> > On 2017/02/28 at 02:14:28, dshwang wrote:
> > > On 2017/02/27 23:10:55, Daniele Castagna wrote:
> > > > Is any device actually using this code path?
> > > > I think this code is exercised only in unit tests.
> > > 
> > > This code is used by both legacy page flip and nuclear page flip. see
> > DrmOverlayValidator::TestPageFlip()
> > 
> > We're not using overlays on Intel ATM. So, this is not exercised, please
correct
> > me if I'm wrong.
> 
> Correct. production code never use it.
> 
> To test this code by chrome, additional commend line is needed
>  * atomic mode setting: --enable-hardware-overlays --enable-drm-atomic

This will eventually work only on devices with 4.4 kernel (i.e: Kaby Lake). So,
why do we need this code if only Kaby Lake will ship with drm atomics?

>  * legacy mode setting: --enable-hardware-overlays

This is never going to ship.

> 
> > Doesn't Intel Kaby Lake support scaling on primary plane? Why do we need
some
> > special code with a late conversion?
> 
> Yes, Kaby Lake and ApolloLake support scaling on primary plane on upstream
kernel. Intel integration team is cherry-picking relevant patches to chromeos
v4.4. As nuclear page flip is available on (near-future) v4.4, we will enable it
from ApolloLake and Kaby Lake. Skylake can support it by hardware tho.

I'm aware and looking forward to that.
We're not going to ship overlays on Skylake and I'd prefer to get rid of this
code that has never been used and will most likely never ship. WDYT?

> 
> Current code includes many experiments. If we want to remain only production
code for ApolloLake or newer, FindOptimalBufferFormat() as well as the special
code can be removed.
> 
> By the way, could you share ARM chromeos status? ARM can support native
scaling and doesn't need this code?

[dshwang, 2017-02-28 04:37:44]

On 2017/02/28 04:06:38, Daniele Castagna wrote:
> > > Doesn't Intel Kaby Lake support scaling on primary plane? Why do we need
> some
> > > special code with a late conversion?
> > 
> > Yes, Kaby Lake and ApolloLake support scaling on primary plane on upstream
> kernel. Intel integration team is cherry-picking relevant patches to chromeos
> v4.4. As nuclear page flip is available on (near-future) v4.4, we will enable
it
> from ApolloLake and Kaby Lake. Skylake can support it by hardware tho.
> 
> I'm aware and looking forward to that.
> We're not going to ship overlays on Skylake and I'd prefer to get rid of this
> code that has never been used and will most likely never ship. WDYT?

good idea. when native scaler is added, let me remove all code including VPP
scaling code (i.e. media::VaapiWrapper::ProcessPixmap())