Implement GpuArcVideoService for arc video accelerator

content/common/gpu/client/gpu_arc_accelerator_host.h

Index: content/common/gpu/client/gpu_arc_accelerator_host.h
diff --git a/content/common/gpu/client/gpu_arc_accelerator_host.h b/content/common/gpu/client/gpu_arc_accelerator_host.h
new file mode 100644
index 0000000000000000000000000000000000000000..fed901579d84a532555d5f7750cd8d346784b6de
--- /dev/null
+++ b/content/common/gpu/client/gpu_arc_accelerator_host.h
@@ -0,0 +1,53 @@
+// Copyright 2015 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.
+
+#ifndef CONTENT_COMMON_GPU_CLIENT_GPU_ARC_ACCELERATOR_HOST_H_
+#define CONTENT_COMMON_GPU_CLIENT_GPU_ARC_ACCELERATOR_HOST_H_
+
+#include <queue>
+
+#include "base/callback.h"
+#include "base/memory/weak_ptr.h"
+#include "base/threading/non_thread_safe.h"
+#include "ipc/ipc_channel_handle.h"
+#include "ipc/ipc_listener.h"
+
+namespace content {
+class GpuChannelHost;
+
+// kcwu: Should this class be folded into GpuProcessHost?

[Owen Lin, 2015/11/23 05:31:06]

TODO(kcwu)?
Sounds good to me.

[kcwu, 2015/11/23 08:11:48]

Now the object calling relationship is
(browser side) GpuArcAcceleratorHost -> GpuChannelHost ->GpuProcessHost
(gpu side) GpuChannelManager -> GpuChannel -> GpuArcAccelerator

If moving GpuArcAcceleratorHost into GpuProcessHost or child of GpuProcessHost
Pros:
 - GpuArcAcceleratorHost does similar to GpuChannelHost, so it sounds good to be
parallel to GpuChannelHost.
Cons:
 - Adding responsibility of GpuProcessHost and GpuChannelManager. I don't know
whether it is good design.
 - We may need to duplicate some code what GpuChannelHost does, to handle
something like BrowserGpuChannelHostFactory.

I am not sure what is better design.

+class GpuArcAcceleratorHost
+    : public IPC::Listener,
+      public base::NonThreadSafe,
+      public base::SupportsWeakPtr<GpuArcAcceleratorHost> {
+ public:
+  using CreatedCallback = base::Callback<void(IPC::ChannelHandle, uint32_t)>;
+  GpuArcAcceleratorHost();
+  ~GpuArcAcceleratorHost() override;
+
+  // IPC::Listener implementation.
+  void OnChannelError() override;
+  bool OnMessageReceived(const IPC::Message& message) override;
+
+  void CreateArcAccelerator(uint32_t device_type, const CreatedCallback& cb);

[Owen Lin, 2015/11/23 05:31:06]

Why need to pass device_type. I would we will do the initialization later. For
the ArcBridgeService, the job is only creating the channel.

Maybe rename it to CreateArcVideoAcceleratorChannel?

[kcwu, 2015/11/23 08:11:48]

The main reason is I want to reduce one IPC round trip for initialize. If the
initial latency is not a concern, I agreed it is cleaner to have a dedicate IPC
message for initialize.

+  void Shutdown();
+
+ private:
+  void AbortPendingRequests();
+  void GpuChannelEstablished(uint32_t device_type, const CreatedCallback& cb);
+  void CreateArcAcceleratorWithGpuChannel(uint32_t device_type,
+                                          const CreatedCallback& cb);
+
+  void OnArcAcceleratorCreated(IPC::ChannelHandle handle, uint32_t result);
+
+  int32_t route_id_;
+  scoped_refptr<GpuChannelHost> gpu_channel_host_;
+  std::queue<CreatedCallback> pending_requests_;
+
+  DISALLOW_COPY_AND_ASSIGN(GpuArcAcceleratorHost);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_COMMON_GPU_CLIENT_GPU_ARC_ACCELERATOR_HOST_H_