Add dmabuf support to ozone scanout buffers.

Add dmabuf support to ozone scanout buffers.

Some scanout buffers may need to be allocated on a device that is separate
from the GPU, for example, a usb monitor or a separate display controller.
For those devices, scanout buffers are shared with the GPU via dmabuf and
we use dmabuf eglimage to render into them.

BUG=380861
Committed: https://crrev.com/0cdb16710c508ca3f3b1f59f195672d9c0b9794a
Cr-Commit-Position: refs/heads/master@{#300118}

[alexst (slow to review), 2014-10-15 18:03:59]

alexst@chromium.org changed reviewers:
+ reveman@chromium.org

[alexst (slow to review), 2014-10-15 18:04:39]

Dave, please take a look. This patch wires up dmabuf GLImage.

[reveman, 2014-10-16 04:07:31]

lgtm with nit

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
File ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc (right):

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc:51: bool
Initialize(scoped_refptr<NativePixmap> pixmap,
nit: "NativePixmap* pixmap" instead

[alexst (slow to review), 2014-10-16 12:46:45]

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
File ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc (right):

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc:51: bool
Initialize(scoped_refptr<NativePixmap> pixmap,
On 2014/10/16 04:07:31, reveman wrote:
> nit: "NativePixmap* pixmap" instead

Is the intention for using raw ptr to avoid ref count churn?

We hold on to a reference to pixmap inside the class, so I thought it would be
more explicit to use scoped_refptr. To me raw pointer signifies that the
function doesn't intend to keep the object.

[reveman, 2014-10-16 13:24:26]

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
File ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc (right):

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc:51: bool
Initialize(scoped_refptr<NativePixmap> pixmap,
On 2014/10/16 12:46:45, alexst wrote:
> On 2014/10/16 04:07:31, reveman wrote:
> > nit: "NativePixmap* pixmap" instead
> 
> Is the intention for using raw ptr to avoid ref count churn?
> 
> We hold on to a reference to pixmap inside the class, so I thought it would be
> more explicit to use scoped_refptr. To me raw pointer signifies that the
> function doesn't intend to keep the object.

scoped_refptr<> is typically only used when passing ownership. We never really
pass ownership of ref counted types using a function parameter. We pass a raw
pointer and it's up to the function to decide if it wants to take a reference to
the object or not. I think using this to indicate that the function "intends" to
keep a reference is sketchy. What if the function fails, does it still take a
reference?

[alexst (slow to review), 2014-10-16 13:40:32]

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
File ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc (right):

https://codereview.chromium.org/656133002/diff/1/ui/ozone/gpu/gpu_memory_buff...
ui/ozone/gpu/gpu_memory_buffer_factory_ozone_native_buffer.cc:51: bool
Initialize(scoped_refptr<NativePixmap> pixmap,
On 2014/10/16 13:24:26, reveman wrote:
> On 2014/10/16 12:46:45, alexst wrote:
> > On 2014/10/16 04:07:31, reveman wrote:
> > > nit: "NativePixmap* pixmap" instead
> > 
> > Is the intention for using raw ptr to avoid ref count churn?
> > 
> > We hold on to a reference to pixmap inside the class, so I thought it would
be
> > more explicit to use scoped_refptr. To me raw pointer signifies that the
> > function doesn't intend to keep the object.
> 
> scoped_refptr<> is typically only used when passing ownership. We never really
> pass ownership of ref counted types using a function parameter. We pass a raw
> pointer and it's up to the function to decide if it wants to take a reference
to
> the object or not. I think using this to indicate that the function "intends"
to
> keep a reference is sketchy. What if the function fails, does it still take a
> reference?

Okay, sounds good.

[alexst (slow to review), 2014-10-16 14:00:03]

alexst@chromium.org changed reviewers:
+ spang@chromium.org

[alexst (slow to review), 2014-10-16 14:00:47]

+spang

[spang, 2014-10-17 16:24:06]

lgtm

[alexst (slow to review), 2014-10-17 16:25:47]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-10-17 16:26:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/656133002/20001

[commit-bot: I haz the power, 2014-10-17 16:48:54]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-10-17 16:49:49]

Patchset 2 (id:??) landed as
https://crrev.com/0cdb16710c508ca3f3b1f59f195672d9c0b9794a
Cr-Commit-Position: refs/heads/master@{#300118}