VaapiVideoAccelerator: make Vaapi accelerator work with ozone

ui/ozone/platform/dri/gbm_buffer.cc

Index: ui/ozone/platform/dri/gbm_buffer.cc
diff --git a/ui/ozone/platform/dri/gbm_buffer.cc b/ui/ozone/platform/dri/gbm_buffer.cc
index 398064da27ec2e7dd90b2c49728aa941d968231b..83e6ae30fe5be810f4df0aac9219ae7391fa26bc 100644
--- a/ui/ozone/platform/dri/gbm_buffer.cc
+++ b/ui/ozone/platform/dri/gbm_buffer.cc
@@ -71,8 +71,11 @@ void* GbmPixmap::GetEGLClientBuffer() {
 }
 
 int GbmPixmap::GetDmaBufFd() {
-  NOTIMPLEMENTED();
-  return -1;
+  return gbm_bo_get_fd(buffer_->bo());

[Pawel Osciak, 2014/10/08 08:17:23]

I think we should be closing the fd somewhere once we are done with it?

[llandwerlin-old, 2014/10/08 09:31:18]

When we give the fd to LibVA, it is wrapped using
drm_intel_bo_gem_create_from_prime :
http://cgit.freedesktop.org/mesa/drm/tree/intel/intel_bufmgr.h?id=86b37c61c78...

Libdrm then does refcounting on the drm_intel_bo objects, and ensure the fd is
closed when unused.

As mentionned https://codereview.chromium.org/490233002/#msg41 , we need some
patches in libdrm (or upgrade to 2.4.57 to have drm BOs properly managed between
GL and LibVA.

[Pawel Osciak, 2014/10/26 13:06:46]

This ends up in DRM_IOCTL_PRIME_FD_TO_HANDLE and that calls get_dma_buf() which
increases the refcount on associated file. Also, the documentation for
gbm_bo_get_fd() says we need to be closing it. And the users such as Wayland are
doing this (e.g.
http://people.freedesktop.org/~chadversary/mesa/doxygen/kevin-rogovin/dd/d68/...).

[llandwerlin-old, 2014/10/29 13:52:47]

Right, thanks, we effectively leaking the fd here. I will add a comment in the
drm picture provider to explain how all this works.

[kalyank, 2014/11/01 18:33:47]

Now, this should be handled with the latest rebase I guess. GBMPixmap will close
the fd during destruction.

+}
+
+uint32_t GbmPixmap::GetStride() {
+  return gbm_bo_get_stride(buffer_->bo());
 }
 
 }  // namespace ui