ozone: Import multi-planar GBMs.

ozone: Import multi-planar GBMs.

https://chromium-review.googlesource.com/#/c/401439/ introduced a new
interface in minigbm to import multiplanar formats.

This CL updates Chromium to use the new interface.
In this way we can add KMS framebuffers for multi-planar formats.

BUG=702750
TEST=ozone_gl_unittests with BGRA and YUV_420_BIPLANAR.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2761533002
Cr-Commit-Position: refs/heads/master@{#458627}
Committed: https://chromium.googlesource.com/chromium/src/+/1958fde835d34e2699213a38e4aae5df4d67c8a1

[Daniele Castagna, 2017-03-17 19:57:51]

Description was changed from

==========
ozone: Import multi-planar GBMs.

https://chromium-review.googlesource.com/#/c/401439/ introduced a new
interface in minigbm to import multiplanar formats.

This CL updates Chromium to use the new interface.
In this way we can add KMS framebuffers for multi-planar formats.

BUG=702750
TEST=ozone_gl_unittests with BGRA and YUV_420_BIPLANAR.
==========

to

==========
ozone: Import multi-planar GBMs.

https://chromium-review.googlesource.com/#/c/401439/ introduced a new
interface in minigbm to import multiplanar formats.

This CL updates Chromium to use the new interface.
In this way we can add KMS framebuffers for multi-planar formats.

BUG=702750
TEST=ozone_gl_unittests with BGRA and YUV_420_BIPLANAR.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Daniele Castagna, 2017-03-17 19:57:55]

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

[commit-bot: I haz the power, 2017-03-17 19:58:27]

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

[Daniele Castagna, 2017-03-17 20:00:15]

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

[Daniele Castagna, 2017-03-17 20:00:23]

dcastagna@chromium.org changed reviewers:
+ gurchetansingh@chromium.org, reveman@chromium.org

[commit-bot: I haz the power, 2017-03-17 20:00:36]

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

[gurchetansingh, 2017-03-17 21:02:09]

Please test running the Youtube app with Minnie or Kevin.

From my experience (b:32726875), you may to modify drm_create_prime_buffer in
server.cc and CreateFromHandle in gpu_memory_buffer_impl_ozone_native_pixmap.cc
so you have an fd associated with all planes (as minigbm expects), not just the
first one. I.e,. I think may have to change this line

>>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
 68                                           true /* auto_close */);

[Daniele Castagna, 2017-03-17 21:39:53]

On 2017/03/17 at 21:02:09, gurchetansingh wrote:
> Please test running the Youtube app with Minnie or Kevin.
> 

I tested it on Kevin with the Youtube app, it seems to work fine. (No overlay
though because there is a big quad on top of the video.)

> From my experience (b:32726875), you may to modify drm_create_prime_buffer in
server.cc and CreateFromHandle in gpu_memory_buffer_impl_ozone_native_pixmap.cc
so you have an fd associated with all planes (as minigbm expects), not just the
first one. I.e,. I think may have to change this line
> 

Minigbm expects an fd for each plane, while eglCreateImageKHR expects the very
same fd number for each plane on some platforms.
So the only way we have to do that right now is to have
handle.native_pixmap_handle.fds.size() == 1 meaning that the very same fd should
be used for all the planes. We can't have handle.native_pixmap_handle.fds.size()
> 1 duping the fds because the image initialization will fail on Intel.


> >>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
>  68                                           true /* auto_close */);
This should change. We're probably getting away with it now because the two fds
I get from the yuv_client are just one dup of the others. Let me fix this.

[commit-bot: I haz the power, 2017-03-17 22:15:17]

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

[commit-bot: I haz the power, 2017-03-17 22:15:18]

Dry run: This issue passed the CQ dry run.

[Daniele Castagna, 2017-03-18 02:08:28]

On 2017/03/17 at 21:39:53, Daniele Castagna wrote:
> On 2017/03/17 at 21:02:09, gurchetansingh wrote:
> > Please test running the Youtube app with Minnie or Kevin.
> > 
> 
> I tested it on Kevin with the Youtube app, it seems to work fine. (No overlay
though because there is a big quad on top of the video.)
> 
> > From my experience (b:32726875), you may to modify drm_create_prime_buffer
in server.cc and CreateFromHandle in
gpu_memory_buffer_impl_ozone_native_pixmap.cc so you have an fd associated with
all planes (as minigbm expects), not just the first one. I.e,. I think may have
to change this line
> > 
> 
> Minigbm expects an fd for each plane, while eglCreateImageKHR expects the very
same fd number for each plane on some platforms.
> So the only way we have to do that right now is to have
handle.native_pixmap_handle.fds.size() == 1 meaning that the very same fd should
be used for all the planes. We can't have handle.native_pixmap_handle.fds.size()
> 1 duping the fds because the image initialization will fail on Intel.
> 
> 
> >
>>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
> >  68                                           true /* auto_close */);
> This should change. We're probably getting away with it now because the two
fds I get from the yuv_client are just one dup of the others. Let me fix this.

After looking at the code a little bit more, I think it's OK not to add support
for multiple fds in this CL. This CL is about importing multi-planar gbms, and
not about fixing the the ambiguities we have about the relation between planes
and native_pixmap_handle.fds.

We should discuss and address that problem in another CL.


To recap what I noticed looking at the code again regarding
native_pixmap_handle.fds:

- eglCreateImageKHR sometimes expects the very same fd for every plane,
otherwise it fails.

- minigbm returns one fd per plane (possibly dups), but it seems ok to import a
buffer if the fd is the same for all the plane. 

- All the buffers in Chrome right now have only one fd.

- The buffers coming from exo are using the drm_create_prime_buffer interface
that supports only one fd.

- arc_gpu_video_decode_accelerator.cc adds only one fd.

- Tests export and re-import pixmap, ending up with only one fd.

The only place where we can get more than one fd is if we use wayland_yuv_simple
client since it is using linux_buffer_params_interface and it can pass more than
one fd. That's why I removed the DCHECK_LE in
GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle.
The browser shouldn't DCHECK something that can come from exo and is a valid
buffer.
It's fine to try to import only one fd though, and in the NV12 case it works
too, since the second fd might just actually be a dup of the first one.

ccing Kristian since he had an opinion about not having a 1-to-1 relation
between fds and planes.

[gurchetansingh, 2017-03-18 03:46:01]

On 2017/03/18 02:08:28, Daniele Castagna wrote:
> On 2017/03/17 at 21:39:53, Daniele Castagna wrote:
> > On 2017/03/17 at 21:02:09, gurchetansingh wrote:
> > > Please test running the Youtube app with Minnie or Kevin.
> > > 
> > 
> > I tested it on Kevin with the Youtube app, it seems to work fine. (No
overlay
> though because there is a big quad on top of the video.)
> > 
> > > From my experience (b:32726875), you may to modify drm_create_prime_buffer
> in server.cc and CreateFromHandle in
> gpu_memory_buffer_impl_ozone_native_pixmap.cc so you have an fd associated
with
> all planes (as minigbm expects), not just the first one. I.e,. I think may
have
> to change this line
> > > 
> > 
> > Minigbm expects an fd for each plane, while eglCreateImageKHR expects the
very
> same fd number for each plane on some platforms.
> > So the only way we have to do that right now is to have
> handle.native_pixmap_handle.fds.size() == 1 meaning that the very same fd
should
> be used for all the planes. We can't have
handle.native_pixmap_handle.fds.size()
> > 1 duping the fds because the image initialization will fail on Intel.
> > 
> > 
> > >
> >>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
> > >  68                                           true /* auto_close */);
> > This should change. We're probably getting away with it now because the two
> fds I get from the yuv_client are just one dup of the others. Let me fix this.
> 
> After looking at the code a little bit more, I think it's OK not to add
support
> for multiple fds in this CL. This CL is about importing multi-planar gbms, and
> not about fixing the the ambiguities we have about the relation between planes
> and native_pixmap_handle.fds.
> 
> We should discuss and address that problem in another CL.
> 
> 
> To recap what I noticed looking at the code again regarding
> native_pixmap_handle.fds:
> 
> - eglCreateImageKHR sometimes expects the very same fd for every plane,
> otherwise it fails.
> 
> - minigbm returns one fd per plane (possibly dups), but it seems ok to import
a
> buffer if the fd is the same for all the plane. 
> 
> - All the buffers in Chrome right now have only one fd.
> 
> - The buffers coming from exo are using the drm_create_prime_buffer interface
> that supports only one fd.
> 
> - arc_gpu_video_decode_accelerator.cc adds only one fd.
> 
> - Tests export and re-import pixmap, ending up with only one fd.
> 
> The only place where we can get more than one fd is if we use
wayland_yuv_simple
> client since it is using linux_buffer_params_interface and it can pass more
than
> one fd. That's why I removed the DCHECK_LE in
> GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle.
> The browser shouldn't DCHECK something that can come from exo and is a valid
> buffer.
> It's fine to try to import only one fd though, and in the NV12 case it works
> too, since the second fd might just actually be a dup of the first one.
> 
> ccing Kristian since he had an opinion about not having a 1-to-1 relation
> between fds and planes.

Aren't we going to hit the case we hit in b:32726875 if we use NV12 is a overlay
and try gbm_bo_import with it?  Specifically, fd[0] will be valid but the rest
the fds will not be.  Minigbm will throw an assert..

Regarding the 1-to-1 relation with fds, we should sort it out during the next
meeting if there's any disagreement.  I was told by my manager more than once we
should have 1 fd per plane, even if it's the same kernel buffer :-)

[Daniele Castagna, 2017-03-18 03:57:27]

On 2017/03/18 at 03:46:01, gurchetansingh wrote:
> On 2017/03/18 02:08:28, Daniele Castagna wrote:
> > On 2017/03/17 at 21:39:53, Daniele Castagna wrote:
> > > On 2017/03/17 at 21:02:09, gurchetansingh wrote:
> > > > Please test running the Youtube app with Minnie or Kevin.
> > > > 
> > > 
> > > I tested it on Kevin with the Youtube app, it seems to work fine. (No
overlay
> > though because there is a big quad on top of the video.)
> > > 
> > > > From my experience (b:32726875), you may to modify
drm_create_prime_buffer
> > in server.cc and CreateFromHandle in
> > gpu_memory_buffer_impl_ozone_native_pixmap.cc so you have an fd associated
with
> > all planes (as minigbm expects), not just the first one. I.e,. I think may
have
> > to change this line
> > > > 
> > > 
> > > Minigbm expects an fd for each plane, while eglCreateImageKHR expects the
very
> > same fd number for each plane on some platforms.
> > > So the only way we have to do that right now is to have
> > handle.native_pixmap_handle.fds.size() == 1 meaning that the very same fd
should
> > be used for all the planes. We can't have
handle.native_pixmap_handle.fds.size()
> > > 1 duping the fds because the image initialization will fail on Intel.
> > > 
> > > 
> > > >
> >
>>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
> > > >  68                                           true /* auto_close */);
> > > This should change. We're probably getting away with it now because the
two
> > fds I get from the yuv_client are just one dup of the others. Let me fix
this.
> > 
> > After looking at the code a little bit more, I think it's OK not to add
support
> > for multiple fds in this CL. This CL is about importing multi-planar gbms,
and
> > not about fixing the the ambiguities we have about the relation between
planes
> > and native_pixmap_handle.fds.
> > 
> > We should discuss and address that problem in another CL.
> > 
> > 
> > To recap what I noticed looking at the code again regarding
> > native_pixmap_handle.fds:
> > 
> > - eglCreateImageKHR sometimes expects the very same fd for every plane,
> > otherwise it fails.
> > 
> > - minigbm returns one fd per plane (possibly dups), but it seems ok to
import a
> > buffer if the fd is the same for all the plane. 
> > 
> > - All the buffers in Chrome right now have only one fd.
> > 
> > - The buffers coming from exo are using the drm_create_prime_buffer
interface
> > that supports only one fd.
> > 
> > - arc_gpu_video_decode_accelerator.cc adds only one fd.
> > 
> > - Tests export and re-import pixmap, ending up with only one fd.
> > 
> > The only place where we can get more than one fd is if we use
wayland_yuv_simple
> > client since it is using linux_buffer_params_interface and it can pass more
than
> > one fd. That's why I removed the DCHECK_LE in
> > GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle.
> > The browser shouldn't DCHECK something that can come from exo and is a valid
> > buffer.
> > It's fine to try to import only one fd though, and in the NV12 case it works
> > too, since the second fd might just actually be a dup of the first one.
> > 
> > ccing Kristian since he had an opinion about not having a 1-to-1 relation
> > between fds and planes.
> 
> Aren't we going to hit the case we hit in b:32726875 if we use NV12 is a
overlay and try gbm_bo_import with it?  Specifically, fd[0] will be valid but
the rest the fds will not be.  Minigbm will throw an assert..
> 

We were passing passing only the fds that we had in the old code
(crrev.com/2448113007):

   for (size_t i = 0; i < fds.size(); ++i)
      fd_data.fds[i] = fds[i].get();

Note that fds.size() might have been smaller than planes.size()

In the new one we repeat the first fd for every plane:

    for (size_t i = 0; i < planes.size(); ++i) {
      fd_data.fds[i] = fds[i < fds.size() ? i : 0].get();
  

> Regarding the 1-to-1 relation with fds, we should sort it out during the next
meeting if there's any disagreement.  I was told by my manager more than once we
should have 1 fd per plane, even if it's the same kernel buffer :-)

Sure, let's bring this up next Tuesday.

[gurchetansingh, 2017-03-21 01:41:44]

On 2017/03/18 03:57:27, Daniele Castagna wrote:
> On 2017/03/18 at 03:46:01, gurchetansingh wrote:
> > On 2017/03/18 02:08:28, Daniele Castagna wrote:
> > > On 2017/03/17 at 21:39:53, Daniele Castagna wrote:
> > > > On 2017/03/17 at 21:02:09, gurchetansingh wrote:
> > > > > Please test running the Youtube app with Minnie or Kevin.
> > > > > 
> > > > 
> > > > I tested it on Kevin with the Youtube app, it seems to work fine. (No
> overlay
> > > though because there is a big quad on top of the video.)
> > > > 
> > > > > From my experience (b:32726875), you may to modify
> drm_create_prime_buffer
> > > in server.cc and CreateFromHandle in
> > > gpu_memory_buffer_impl_ozone_native_pixmap.cc so you have an fd associated
> with
> > > all planes (as minigbm expects), not just the first one. I.e,. I think may
> have
> > > to change this line
> > > > > 
> > > > 
> > > > Minigbm expects an fd for each plane, while eglCreateImageKHR expects
the
> very
> > > same fd number for each plane on some platforms.
> > > > So the only way we have to do that right now is to have
> > > handle.native_pixmap_handle.fds.size() == 1 meaning that the very same fd
> should
> > > be used for all the planes. We can't have
> handle.native_pixmap_handle.fds.size()
> > > > 1 duping the fds because the image initialization will fail on Intel.
> > > > 
> > > > 
> > > > >
> > >
> >>native_pixmap_handle.fds.emplace_back(handle.native_pixmap_handle.fds[0].fd,
> > > > >  68                                           true /* auto_close */);
> > > > This should change. We're probably getting away with it now because the
> two
> > > fds I get from the yuv_client are just one dup of the others. Let me fix
> this.
> > > 
> > > After looking at the code a little bit more, I think it's OK not to add
> support
> > > for multiple fds in this CL. This CL is about importing multi-planar gbms,
> and
> > > not about fixing the the ambiguities we have about the relation between
> planes
> > > and native_pixmap_handle.fds.
> > > 
> > > We should discuss and address that problem in another CL.
> > > 
> > > 
> > > To recap what I noticed looking at the code again regarding
> > > native_pixmap_handle.fds:
> > > 
> > > - eglCreateImageKHR sometimes expects the very same fd for every plane,
> > > otherwise it fails.
> > > 
> > > - minigbm returns one fd per plane (possibly dups), but it seems ok to
> import a
> > > buffer if the fd is the same for all the plane. 
> > > 
> > > - All the buffers in Chrome right now have only one fd.
> > > 
> > > - The buffers coming from exo are using the drm_create_prime_buffer
> interface
> > > that supports only one fd.
> > > 
> > > - arc_gpu_video_decode_accelerator.cc adds only one fd.
> > > 
> > > - Tests export and re-import pixmap, ending up with only one fd.
> > > 
> > > The only place where we can get more than one fd is if we use
> wayland_yuv_simple
> > > client since it is using linux_buffer_params_interface and it can pass
more
> than
> > > one fd. That's why I removed the DCHECK_LE in
> > > GpuMemoryBufferImplOzoneNativePixmap::CreateFromHandle.
> > > The browser shouldn't DCHECK something that can come from exo and is a
valid
> > > buffer.
> > > It's fine to try to import only one fd though, and in the NV12 case it
works
> > > too, since the second fd might just actually be a dup of the first one.
> > > 
> > > ccing Kristian since he had an opinion about not having a 1-to-1 relation
> > > between fds and planes.
> > 
> > Aren't we going to hit the case we hit in b:32726875 if we use NV12 is a
> overlay and try gbm_bo_import with it?  Specifically, fd[0] will be valid but
> the rest the fds will not be.  Minigbm will throw an assert..
> > 
> 
> We were passing passing only the fds that we had in the old code
> (crrev.com/2448113007):
> 
>    for (size_t i = 0; i < fds.size(); ++i)
>       fd_data.fds[i] = fds[i].get();
> 
> Note that fds.size() might have been smaller than planes.size()
> 
> In the new one we repeat the first fd for every plane:
> 
>     for (size_t i = 0; i < planes.size(); ++i) {
>       fd_data.fds[i] = fds[i < fds.size() ? i : 0].get();
>   
> 
> > Regarding the 1-to-1 relation with fds, we should sort it out during the
next
> meeting if there's any disagreement.  I was told by my manager more than once
we
> should have 1 fd per plane, even if it's the same kernel buffer :-)
> 
> Sure, let's bring this up next Tuesday.

lgtm

[reveman, 2017-03-21 03:36:09]

lgtm % nits

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:192: struct gbm_import_fd_planar_data
fd_data {};
nit: leave uninitialized so asan can detect if gbm_bo_import is using part of
this struct that is not supposed to be used

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:199: fd_data.fds[i] = fds[i < fds.size()
? i : 0].get();
what if fds.size() is 2 and planes.size() is 3. do we want fd_data.fds[1] to be
fds[1] or fds[0]? should this function fail if fds.size() is not 1 or
planes.size()?

[Daniele Castagna, 2017-03-21 03:45:40]

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

[commit-bot: I haz the power, 2017-03-21 03:45:50]

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

[Daniele Castagna, 2017-03-21 03:47:08]

dcastagna@chromium.org changed reviewers:
+ dnicoara@chromium.org

[Daniele Castagna, 2017-03-21 03:47:09]

+dnicoara for ownership.

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:192: struct gbm_import_fd_planar_data
fd_data {};
On 2017/03/21 at 03:36:09, reveman wrote:
> nit: leave uninitialized so asan can detect if gbm_bo_import is using part of
this struct that is not supposed to be used

Done.

https://codereview.chromium.org/2761533002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:199: fd_data.fds[i] = fds[i < fds.size()
? i : 0].get();
On 2017/03/21 at 03:36:09, reveman wrote:
> what if fds.size() is 2 and planes.size() is 3. do we want fd_data.fds[1] to
be fds[1] or fds[0]? 

This is consistent with what we do for
eglCreateImageKHR:GLImageNativePixmap::Initialize

If we want to change it, I'm happy to follow up with another CL that changes the
behavior in both places.

> should this function fail if fds.size() is not 1 or planes.size()?

As discussed offline. If we want to enforce if the number of fds to be 1 or
fds.size(), we should filter other configurations in exo.

I'm starting another thread about the relation between fds and planes because,
as it's clear from comments on this CL, it's not clear with the current state of
things.

[commit-bot: I haz the power, 2017-03-21 04:26:42]

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

[commit-bot: I haz the power, 2017-03-21 04:26:43]

Dry run: This issue passed the CQ dry run.

[dnicoara, 2017-03-21 14:48:56]

lgtm % nit

https://codereview.chromium.org/2761533002/diff/60001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/2761533002/diff/60001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:197: DCHECK_LT(planes.size(), 3u);
Should this be DCHECK_LE?

[Daniele Castagna, 2017-03-22 00:01:05]

https://codereview.chromium.org/2761533002/diff/60001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/2761533002/diff/60001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:197: DCHECK_LT(planes.size(), 3u);
On 2017/03/21 at 14:48:56, dnicoara wrote:
> Should this be DCHECK_LE?

Yes. Done, thank you for noticing it.

[Daniele Castagna, 2017-03-22 00:01:18]

The CQ bit was checked by dcastagna@chromium.org

[Daniele Castagna, 2017-03-22 00:01:19]

The patchset sent to the CQ was uploaded after l-g-t-m from
reveman@chromium.org, gurchetansingh@chromium.org, dnicoara@chromium.org
Link to the patchset: https://codereview.chromium.org/2761533002/#ps80001
(title: "LE not LT.")

[commit-bot: I haz the power, 2017-03-22 00:01:56]

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-03-22 02:04:18]

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

[commit-bot: I haz the power, 2017-03-22 02:04:20]

Try jobs failed on following builders:
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_TIMED_OUT,
build hasn't started yet, builder probably lacks capacity)

[Daniele Castagna, 2017-03-22 02:30:07]

The CQ bit was checked by dcastagna@chromium.org

[commit-bot: I haz the power, 2017-03-22 02:31:14]

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-03-22 04:36:10]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1490149807901750,
"parent_rev": "8bbad22818fe3099727bd41b40f14824281043ae", "commit_rev":
"1958fde835d34e2699213a38e4aae5df4d67c8a1"}

[commit-bot: I haz the power, 2017-03-22 04:37:11]

Description was changed from

==========
ozone: Import multi-planar GBMs.

https://chromium-review.googlesource.com/#/c/401439/ introduced a new
interface in minigbm to import multiplanar formats.

This CL updates Chromium to use the new interface.
In this way we can add KMS framebuffers for multi-planar formats.

BUG=702750
TEST=ozone_gl_unittests with BGRA and YUV_420_BIPLANAR.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
ozone: Import multi-planar GBMs.

https://chromium-review.googlesource.com/#/c/401439/ introduced a new
interface in minigbm to import multiplanar formats.

This CL updates Chromium to use the new interface.
In this way we can add KMS framebuffers for multi-planar formats.

BUG=702750
TEST=ozone_gl_unittests with BGRA and YUV_420_BIPLANAR.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2761533002
Cr-Commit-Position: refs/heads/master@{#458627}
Committed:
https://chromium.googlesource.com/chromium/src/+/1958fde835d34e2699213a38e4aa...
==========

[commit-bot: I haz the power, 2017-03-22 04:37:12]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/1958fde835d34e2699213a38e4aa...