Add command_buffer_gles2

gpu/command_buffer_gles2/command_buffer_gles2.gyp

Index: gpu/command_buffer_gles2/command_buffer_gles2.gyp
diff --git a/gpu/command_buffer_gles2/command_buffer_gles2.gyp b/gpu/command_buffer_gles2/command_buffer_gles2.gyp
new file mode 100644
index 0000000000000000000000000000000000000000..ea953bd4a8ed3a6bcd445da00074f57ef1dec759
--- /dev/null
+++ b/gpu/command_buffer_gles2/command_buffer_gles2.gyp
@@ -0,0 +1,28 @@
+# Copyright (c) 2015 The Chromium Authors. All rights reserved.

[no sievers, 2015/08/27 19:21:28]

nit: drop '(c)'

[hendrikw, 2015/08/27 20:34:44]

Done.

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+{
+  'variables': {
+    'chromium_code': 1,
+  },
+  'targets': [
+    {
+      # GN version: //gpu:command_buffer_gles2
+      'target_name': 'command_buffer_gles2',
+      'type': 'shared_library',
+      'dependencies': [
+        '../../gpu/gles2_conform_support/gles2_conform_support.gyp:egl_native',

[no sievers, 2015/08/27 22:02:25]

This actually also depends on all the GPU stuff. But it pulls in
gles2_implementation_no_check, while below depends on gles2_implementation.
Doesn't that lead to duplicate symbols for everything?

It also feels like an abuse to use the conformance test stuff here.
Does it have the same effect to pull in the needed stuff from the 'egl_native'
dependency list here directly?

[hendrikw, 2015/08/28 16:01:51]

Hmm, gles2_c_lib didn't have a dependency on gles2_implementation, I guess
that's why I didn't have duplicate symbols.

That said, it's still a bit weird to have a mix of _no_check.  Including the
conformance test source files directly is a great idea (though still seems like
a bit of abuse).  Done.

Maybe we can later move the egl stuff out of the conform_support folder.

[no sievers, 2015/08/28 17:59:31]

Sounds good. You should probably put a TODO for that next to the included
conform_support sources in here and GN.

[hendrikw, 2015/08/28 18:10:24]

Done.

+        '../../gpu/gpu.gyp:gles2_c_lib',

[no sievers, 2015/08/27 19:21:28]

So how are you planning on using this overall?
This doesn't seem to be pulling in all the cmdbuffer client code.
And where will the service be?

[hendrikw, 2015/08/27 20:34:44]

I started out with more dependencies, and pulled the ones I didn't need out.

I don't think this needs the client code.

BTW, Skia's DM, nanobench, SampleApp, and maybe Visual dm will be the clients.

You can see the changes made to skia to allow this here:
https://codereview.chromium.org/1306823003/

[no sievers, 2015/08/27 22:02:25]

Ah because gles2_c_lib already depends on command_buffer_client. I'd
double-check that that works for GN though.

So once skia writes stuff in the command buffer, what's supposed to happen with
the commands in the buffer?

[hendrikw, 2015/08/28 16:01:51]

They get played :D

(Flush->ProcessCommands->Decode->ANGLE)

+      ],
+      'sources': [
+        # Note: sources list duplicated in GN build.
+        'command_buffer_egl.cc',
+      ],
+      'defines': [
+        'EGLAPI=',
+        'EGLAPIENTRY=',
+      ],
+    },
+  ],
+}