Implement GpuArcVideoService for arc video accelerator

content/common/gpu/gpu_messages.h

Index: content/common/gpu/gpu_messages.h
diff --git a/content/common/gpu/gpu_messages.h b/content/common/gpu/gpu_messages.h
index ecb19796f6fc9dfea6abdfe37ee61738104eeae6..cdf581710af961625321df1a11680e5de06ce90f 100644
--- a/content/common/gpu/gpu_messages.h
+++ b/content/common/gpu/gpu_messages.h
@@ -821,3 +821,39 @@ IPC_MESSAGE_ROUTED0(AcceleratedJpegDecoderMsg_Destroy)
 IPC_MESSAGE_ROUTED2(AcceleratedJpegDecoderHostMsg_DecodeAck,
                     int32, /* bitstream_buffer_id */
                     media::JpegDecodeAccelerator::Error /* error */)
+
+IPC_MESSAGE_CONTROL1(GpuMsg_CreateArcAccelerator, int32_t /* device_type */)

[Pawel Osciak, 2015/11/24 10:41:14]

Perhaps we should use an enum for device type? IPC will do a range check on it
for us then.

Here and for other such values below perhaps...

+IPC_MESSAGE_CONTROL0(GpuMsg_ShutdownArcAccelerators)

[Pawel Osciak, 2015/11/24 10:41:14]

Would this allow one instance to shut down all the others? If so, this would be
an issue if we are aiming at instance isolation?

[kcwu, 2015/11/24 13:02:43]

This message is only used when Chrome browser process want to shutdown gpu
process. IPC messages sending by instance directly are start at line 832.

+IPC_MESSAGE_CONTROL2(GpuHostMsg_ArcAcceleratorCreated,
+                     IPC::ChannelHandle /* handle to channel */,
+                     uint32_t /* initialization status */)
+
+// TODO in this CL(kcwu) create a new gpu_arc_messages.h ?
+IPC_SYNC_MESSAGE_CONTROL5_1(ArcAcceleratorMsg_BindSharedBuffer,

[Pawel Osciak, 2015/11/24 10:41:14]

s/SharedBuffer/SharedMemory/ ?

[kcwu, 2015/11/24 13:02:43]

The message name and following types just follow the ArcVideoAccelerator
interface.

+                            uint32_t /* port */,
+                            size_t /* index */,
+                            base::FileDescriptor /* ashmem fd */,
+                            size_t /* offset */,

[Pawel Osciak, 2015/11/24 10:41:14]

off_t?

+                            size_t /* length */,
+                            uint32_t /* result */)

[Pawel Osciak, 2015/11/24 10:41:14]

Do we need more results than a bool success/false?

+IPC_SYNC_MESSAGE_CONTROL3_1(ArcAcceleratorMsg_BindGraphicBuffer,
+                            uint32_t /* port */,
+                            size_t /* index */,
+                            base::FileDescriptor /* dmabuf fd */,
+                            uint32_t /* result */)
+IPC_SYNC_MESSAGE_CONTROL2_1(ArcAcceleratorMsg_UseBuffer,
+                            uint32_t /* port */,
+                            size_t /* index */,
+                            uint32_t /* result */)
+IPC_SYNC_MESSAGE_CONTROL2_2(ArcAcceleratorMsg_SetBufferCount,
+                            uint32_t /* port */,

[Pawel Osciak, 2015/11/24 10:41:14]

Do we need port if we specify both in and out counts?

[kcwu, 2015/11/24 13:02:43]

Ah, my variable name seems confusing.
This is a sync message, |in_count| is the request, |out_count| is the response.

+                            size_t /* in_count */,
+                            size_t /* out_count */,
+                            size_t /* result */)
+IPC_SYNC_MESSAGE_CONTROL0_0(ArcAcceleratorMsg_Reset)
+IPC_SYNC_MESSAGE_CONTROL4_1(ArcAcceleratorMsg_SetPixelFormat,
+                            uint32_t /* port */,
+                            uint32_t /* pixel_format */,
+                            uint32_t /* image_size */,
+                            uint32_t /* memory_type */,
+                            uint32_t /* result */)

[Pawel Osciak, 2015/11/24 10:41:14]

Do we need an Error notification message that would be sent back to client,
similar to NotifyError in VDA?

[kcwu, 2015/11/24 13:02:43]

Yes, there is a new callback onError(). I will add it when I sync ipc messages
with the new interface.