NotForReview: Implement zero/one-copy texture for ozone freon using Intel DRM

NotForReview: Implement zero/one-copy texture for ozone freon using Intel DRM

This CL depends on https://codereview.chromium.org/1134993003/
It's implemented to compare performance between VGEM and Intel DRM.
--ozone-use-intel-drm switch enables Intel DRM backend in runtime.

All code using Intel DRM are in IntelDrmPixmap class. Both GPU process and Renderer use
this class like below examples;

GPU process:
1. IntelDrmPixmap::Create()
2. Send GetDmaBufFd() to Renderer

Renderer:
1. IntelDrmPixmap::CreateFromHandle() using dma_buf
2. Map()/Unmap()
3. ~IntelDrmPixmap()

GPU process:
3. ~IntelDrmPixmap()

Inspired by previous works:
  fjhenigman@chromium.org, https://codereview.chromium.org/186123006
  kalyan.kondapally@intel.com, https://codereview.chromium.org/211133005
  reveman@chromium.org, https://codereview.chromium.org/225023009

TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --user-data-dir=/home/chronos --login-manager --enable-native-gpu-memory-buffers --ozone-use-intel-drm on amd64_generic_freon image
BUG=475633
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

[dshwang, 2015-04-09 18:58:12]

dongseong.hwang@intel.com changed reviewers:
+ alexst@chromium.org, kalyan.kondapally@chromium.org, reveman@chromium.org,
tiago.vignatti@intel.com

[dshwang, 2015-04-09 19:12:26]

reveman@, could you review this ongoing effort? I need your advice. It's based
on your previous work.

kalyank_@, could you review this ongoing effort? It's based on your previous
work, too :)

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
cc/resources/resource_provider.cc:707: // ContextGL()->Finish();
This glFinish almost fix the glitch bug.
So I try to delete |gpu_memory_buffer| in GPU Process 1 sec after receiving
GpuMsg_DestroyGpuMemoryBuffer message without glFinish, but it doesn't fix the
bug. It might be drm bug in linux kernel, but I'm finding workaround in chromium

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:168:
Allow())
Render process requires additional ioctl calls. It's same way in which Android
and OSX add more system call in white list.
I hope security owner review it.

https://codereview.chromium.org/1071273002/diff/1/ui/ozone/platform/drm/gpu/g...
File ui/ozone/platform/drm/gpu/gbm_map_pixmap_intel.cc (right):

https://codereview.chromium.org/1071273002/diff/1/ui/ozone/platform/drm/gpu/g...
ui/ozone/platform/drm/gpu/gbm_map_pixmap_intel.cc:151: //
drm_intel_bo_unreference(buffer_);
As comment said, this CL has glitch and crash bugs. I'm debugging how can I
workaround. This is why I submit few CL about zero-copy recently.

@kalyank_ ,dose drm_intel_bo_gem_export_to_prime() unref drm_intel_bo instance
internally? after drm_intel_bo_gem_export_to_prime(), if I call 
drm_intel_bo_unreference() , gpu process sometimes die with error log
"intel_do_flush_locked failed: Invalid argument"

[dshwang, 2015-04-09 19:13:26]

dongseong.hwang@intel.com changed reviewers:
+ fjhenigman@chromium.org

[dshwang, 2015-04-09 19:19:10]

> @kalyank_ ,dose drm_intel_bo_gem_export_to_prime() unref drm_intel_bo instance
> internally? after drm_intel_bo_gem_export_to_prime(), if I call 
> drm_intel_bo_unreference() , gpu process sometimes die with error log
> "intel_do_flush_locked failed: Invalid argument"

It's full log of Intel drm buf;
https://gist.github.com/ds-hwang/7565587062a67de02ae2

[reveman, 2015-04-13 00:46:13]

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
cc/resources/resource_provider.cc:2066: // TODO(reveman):
GL_COMMANDS_ISSUED_CHROMIUM is used for synchronization
We'll need to fix this TODO instead.

https://codereview.chromium.org/1071273002/diff/1/content/browser/gpu/browser...
File content/browser/gpu/browser_gpu_channel_host_factory.cc (right):

https://codereview.chromium.org/1071273002/diff/1/content/browser/gpu/browser...
content/browser/gpu/browser_gpu_channel_host_factory.cc:265: case
gfx::OZONE_NATIVE_BUFFER:
This change can land separately and it not currently blocked on anything.

https://codereview.chromium.org/1071273002/diff/1/content/common/gpu/client/g...
File content/common/gpu/client/gpu_memory_buffer_impl_ozone_gbm_intel.h (right):

https://codereview.chromium.org/1071273002/diff/1/content/common/gpu/client/g...
content/common/gpu/client/gpu_memory_buffer_impl_ozone_gbm_intel.h:17: class
GpuMemoryBufferImplOzoneGbmIntel
It should either be implemented behind OzoneNativeBuffer or as a different type
of GpuMemoryBuffer that is not limited to ozone. Is this ozone specific or can
it be used with a standard linux build of chromium?

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:168:
Allow())
On 2015/04/09 at 19:12:26, dshwang wrote:
> Render process requires additional ioctl calls. It's same way in which Android
and OSX add more system call in white list.
> I hope security owner review it.

This has unacceptable security implications, which is why we want to use vgem
instead.

https://codereview.chromium.org/1071273002/diff/1/ui/gfx/gpu_memory_buffer.h
File ui/gfx/gpu_memory_buffer.h (right):

https://codereview.chromium.org/1071273002/diff/1/ui/gfx/gpu_memory_buffer.h#...
ui/gfx/gpu_memory_buffer.h:36: uint32 stride;
GpuMemoryBufferHandle should not be used to pass buffer configurations. The code
that determines the stride for a given format and size is ideally shared between
service and client.

https://codereview.chromium.org/1071273002/diff/1/ui/gfx/gpu_memory_buffer.h#...
ui/gfx/gpu_memory_buffer.h:37: base::SharedMemoryHandle device_handle;
Just use |handle| instead.

[dshwang, 2015-04-14 13:15:55]

I just answered comments in deprecated intel drm implementation. I will use vgem
instead of intel drm.

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/1071273002/diff/1/cc/resources/resource_provi...
cc/resources/resource_provider.cc:2066: // TODO(reveman):
GL_COMMANDS_ISSUED_CHROMIUM is used for synchronization
On 2015/04/13 00:46:13, reveman wrote:
> We'll need to fix this TODO instead.

It's Exynos 5 workaround. Even if vgem one-copy is landed, it's behind
--enable-native-gpu-memory-buffers flags. So software one-copy in Exynos 5 still
has this issue. It would be fixed in separate CL.

https://codereview.chromium.org/1071273002/diff/1/content/browser/gpu/browser...
File content/browser/gpu/browser_gpu_channel_host_factory.cc (right):

https://codereview.chromium.org/1071273002/diff/1/content/browser/gpu/browser...
content/browser/gpu/browser_gpu_channel_host_factory.cc:265: case
gfx::OZONE_NATIVE_BUFFER:
On 2015/04/13 00:46:13, reveman wrote:
> This change can land separately and it not currently blocked on anything.

got it

https://codereview.chromium.org/1071273002/diff/1/content/common/gpu/client/g...
File content/common/gpu/client/gpu_memory_buffer_impl_ozone_gbm_intel.h (right):

https://codereview.chromium.org/1071273002/diff/1/content/common/gpu/client/g...
content/common/gpu/client/gpu_memory_buffer_impl_ozone_gbm_intel.h:17: class
GpuMemoryBufferImplOzoneGbmIntel
On 2015/04/13 00:46:13, reveman wrote:
> It should either be implemented behind OzoneNativeBuffer or as a different
type
> of GpuMemoryBuffer that is not limited to ozone. Is this ozone specific or can
> it be used with a standard linux build of chromium?

behind OzoneNativeBuffer. It's ozone specific because it require Ozone GBM.

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/1071273002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:168:
Allow())
On 2015/04/13 00:46:13, reveman wrote:
> On 2015/04/09 at 19:12:26, dshwang wrote:
> > Render process requires additional ioctl calls. It's same way in which
Android
> and OSX add more system call in white list.
> > I hope security owner review it.
> 
> This has unacceptable security implications, which is why we want to use vgem
> instead.

Even if we use vgem, we need some ioctl call in render process to map/unmap
for example, DRM_IOCTL_PRIME_FD_TO_HANDLE, DRM_IOCTL_MODE_MAP_DUMB

[dshwang, 2015-05-11 13:32:30]

I submit vgem implementation in https://codereview.chromium.org/1134993003/
I remain this CL for history. Marked as "Not for Review"

[dshwang, 2015-05-14 15:44:10]

dongseong.hwang@intel.com changed reviewers:
- alexst@chromium.org, fjhenigman@chromium.org, reveman@chromium.org

[dshwang, 2015-06-29 15:20:45]

Patchset #2 (id:20001) has been deleted

[dshwang, 2015-06-29 17:22:05]

Re-implement this based on https://codereview.chromium.org/1134993003/
--ozone-use-intel-drm switch enables Intel DRM backend in runtime.

https://codereview.chromium.org/1071273002/diff/40001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/intel_drm_pixmap.h (right):

https://codereview.chromium.org/1071273002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/intel_drm_pixmap.h:18: class IntelDrmPixmap : public
NativePixmap {
All code using Intel DRM are in this class. Both GPU process and Renderer use
this class like below examples;

GPU process:
1. IntelDrmPixmap::Create()
2. Send GetDmaBufFd() to Renderer

Renderer:
1. IntelDrmPixmap::CreateFromHandle() using dam_buf
2. Map()/Unmap()
3. ~IntelDrmPixmap()

GPU process:
3. ~IntelDrmPixmap()

[dshwang, 2015-06-29 17:42:07]

https://codereview.chromium.org/1071273002/diff/40001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_display_host_manager.cc (right):

https://codereview.chromium.org/1071273002/diff/40001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_display_host_manager.cc:173: device_fd =
primary_drm_device_file_.get();
When --ozone-use-intel-drm, "/dev/dri/card0" is sent to Renderer, instead of
VGEM fd. This CL didn't rename vgem_fd_ to minimize the changes.

[dshwang, 2015-06-29 17:57:29]

Patchset #3 (id:60001) has been deleted

[dshwang, 2015-08-21 10:28:06]

Patchset #5 (id:120001) has been deleted

[jonnialva90, 2016-05-25 12:19:18]

jonnialva90@gmail.com changed reviewers:
+ jonnialva90@gmail.com