Impl mus::mojom::GpuService to enable using Chrome IPC version gpu CmdBuf in mus

components/mus/public/cpp/lib/gpu_service.cc

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "components/mus/public/cpp/gpu_service.h"
+
+#include "base/command_line.h"
+#include "components/mus/common/gpu_type_converters.h"
+#include "components/mus/common/switches.h"
+#include "components/mus/public/cpp/lib/gpu_memory_buffer_manager_mus.h"
+#include "components/mus/public/interfaces/gpu_service.mojom.h"
+#include "gpu/ipc/client/gpu_channel_host.h"
+#include "services/shell/public/cpp/connector.h"
+
+namespace mus {
+
+namespace {
+
+void GpuChannelEstablishCallback(int* client_id_out,
+                                 IPC::ChannelHandle* channel_handle_out,
+                                 gpu::GPUInfo* gpu_info_out,
+                                 int client_id,
+                                 mus::mojom::ChannelHandlePtr channel_handle,
+                                 mus::mojom::GpuInfoPtr gpu_info) {
+  *client_id_out = client_id;
+  *channel_handle_out = channel_handle.To<IPC::ChannelHandle>();
+  // TODO(penghuang): Get the gpu info.
+}
+
+base::LazyInstance<GpuService> g_gpu_service = LAZY_INSTANCE_INITIALIZER;
+}
+
+GpuService::GpuService()
+    : initialized_(false),
+      main_message_loop_(base::MessageLoop::current()),
+      shutdown_event_(false, false),
+      io_thread_("GPUIOThread") {}

[Fady Samuel, 2016/05/25 17:06:47]

This seems odd. Why are we forcing a new thread upon clients.

[Peng, 2016/05/25 19:42:56]

This class is used in client process. Every client process only has one instance
of this class. So just one extra GPU IO
thread in client process.

I also check the mojo code. Seems there is not a good way to access mojo's IO
thread. so we have to create a dedicated IO thread right now.

+
+GpuService::~GpuService() {}
+
+// static
+bool GpuService::UseChromeGpuCommandBuffer() {

[Fady Samuel, 2016/05/25 17:06:47]

Do we need this?

[Peng, 2016/05/25 19:42:56]

Yes. Probably we can hide this switch in client side library, but it will need
change interface of GLES2Context. I would like to avoid it in this CL and do the
refactor later.

+  return base::CommandLine::ForCurrentProcess()->HasSwitch(
+      switches::kUseChromeGpuCommandBufferInMus);
+}
+
+// static
+void GpuService::Initialize(shell::Connector* connector) {
+  g_gpu_service.Get().Init(connector);
+}
+
+// static
+GpuService* GpuService::GetInstance() {
+  DCHECK(!(g_gpu_service == nullptr));
+  return g_gpu_service.Pointer();
+}
+
+void GpuService::Init(shell::Connector* connector) {
+  if (initialized_)
+    return;
+  initialized_ = true;
+
+  base::Thread::Options thread_options(base::MessageLoop::TYPE_IO, 0);
+  thread_options.priority = base::ThreadPriority::NORMAL;
+  CHECK(io_thread_.StartWithOptions(thread_options));
+
+  mus::mojom::GpuServicePtr gpu_service;
+  connector->ConnectToInterface("mojo:mus", &gpu_service);
+
+  const bool preempts = false;
+  const bool allow_view_command_buffers = false;
+  const bool allow_real_time_streams = false;
+  int client_id = 0;
+  IPC::ChannelHandle channel_handle;
+  gpu::GPUInfo gpu_info;
+  gpu_service->EstablishGpuChannel(
+      preempts, allow_view_command_buffers, allow_real_time_streams,
+      base::Bind(&GpuChannelEstablishCallback, &client_id, &channel_handle,
+                 &gpu_info));
+  CHECK(gpu_service.WaitForIncomingResponse());

[piman, 2016/05/24 22:46:54]

I assume this can return false if the mus process dies. What will be the
strategy to handle this case?

[Peng, 2016/05/25 19:42:56]

I don't what should we do for it, so I just make it crash for now. Any
suggestion?

[piman, 2016/05/25 22:53:17]

In Chrome, in RenderThreadImpl, we create the channel lazily, when the first
client creates a command buffer. If creating the channel fails, we fail the
command buffer creation, but we allow the client to retry, or it may fallback
(e.g. to software). If the client retries, the browser (which services the
EstablishGpuChannel) tries to recreate a GPU process. I imagine something
similar will happen with the mus process.

Similarly, if the channel was successfully created, but later on the GPU process
(respectively, the mus process) crashes, later requests to create command
buffers will fail, but the RenderThreadImpl code (respectively this GpuService?)
attempts to recreate a channel before failing.

Maybe this all doesn't have to be solved now, or maybe not solved the same way,
but given the levels of GPU crash rate (even only on Chrome OS), I think this
needs to be addressed at some point. In particular I think it's important to
have an API that allows it to work, so just vending a static GpuChannelHost may
not be enough.

[Peng, 2016/05/31 14:24:03]

I renamed the Init() to EstablishGpuChannel(), and this function will establish
the gpu channel
if the channel is null or it is lost.

Done

+  gpu_memory_buffer_manager_.reset(new mus::GpuMemoryBufferManagerMus());
+  gpu_channel_ = gpu::GpuChannelHost::Create(this, client_id, gpu_info,
+                                             channel_handle, &shutdown_event_,
+                                             gpu_memory_buffer_manager_.get());
+}
+
+bool GpuService::IsMainThread() {
+  return base::MessageLoop::current() == main_message_loop_;
+}
+
+scoped_refptr<base::SingleThreadTaskRunner>
+GpuService::GetIOThreadTaskRunner() {
+  return io_thread_.task_runner();
+}
+
+std::unique_ptr<base::SharedMemory> GpuService::AllocateSharedMemory(
+    size_t size) {
+  std::unique_ptr<base::SharedMemory> shm(new base::SharedMemory());
+  if (!shm->CreateAnonymous(size))
+    return std::unique_ptr<base::SharedMemory>();
+  return shm;
+}
+
+}  // namespace mus