Command to mark surface inactive, so gpu process can release resources.

gpu/command_buffer/build_gles2_cmd_buffer.py

Index: gpu/command_buffer/build_gles2_cmd_buffer.py
diff --git a/gpu/command_buffer/build_gles2_cmd_buffer.py b/gpu/command_buffer/build_gles2_cmd_buffer.py
index f4cd5f24da1177db3317097a965f2c70344d1ada..faeedc3eb84e8c022aa469901a54ebadb0ef6997 100755
--- a/gpu/command_buffer/build_gles2_cmd_buffer.py
+++ b/gpu/command_buffer/build_gles2_cmd_buffer.py
@@ -223,6 +223,7 @@ GL_APICALL void         GL_APIENTRY glPlaceholder447CHROMIUM (void);
 GL_APICALL void         GL_APIENTRY glPlaceholder451CHROMIUM (void);
 GL_APICALL void         GL_APIENTRY glPlaceholder452CHROMIUM (void);
 GL_APICALL void         GL_APIENTRY glPlaceholder453CHROMIUM (void);
+GL_APICALL void         GL_APIENTRY glSetSurfaceVisibleCHROMIUM (GLboolean visible);

[apatrick_chromium, 2011/09/28 17:33:45]

Is there any reason why changing surface visibility can't be requested using an
IPC message. If the IPC message follows a call to flush() it will be effectively
"in-band" with the GL command stream. 

[mmocny, 2011/09/28 21:37:33]

I originally assumed we would not need the flush, and so I had to use a gl
command.
However, I found that this glSetSurfaceVisibleCHROMIUM command was not always
appropriately sent to the gpu process without a flush.  It wasn't just that it
was delayed by some #of ms, rather it wasn't sent at all until further gl
commands are issued.

I am not sure how the command stream decides when to push, but if I do end up
relying on the flush, then you are right, that same flush allows me to just use
an IPC message anyway.

So, a few questions for you:
1) Is there perhaps a less heavy handed way to make sure the message is
delivered?
2) If I switch to using an IPC message, the glflush guarantees it will be
processed after outstanding gl commands, but how do I guarantee it will be
processed before any subsequent ones? (this needs to be true in the
setVisibility(true) case.)

Thanks.

On 2011/09/28 17:33:45, apatrick_chromium wrote:

[apatrick_chromium, 2011/09/28 22:29:45]

OpenGL does not guarantee that a GL command will be executed until after glFlush
or some other synchronizing event happens. It can be held up indefinitely.
glFlush will work. It is stronger than you need because it will glFlush the
underlying GL backend unnecessarily. GLES2CmdHelper::Flush is cheaper and all
you need.
IPCs, including the async IPC that signals the flush, are not reordered on the
channel so the the flush before the set visibility IPC is a barrier and the set
visibility IPC itself is a barrier wrt to ordering of GL commands.

[mmocny, 2011/10/07 14:26:13]

GLES2CmdHelper::Flush seems to only add a glFlush into the command stream, but
that led me to find CommandBufferHelper::Flush which is I think what you
intended.

On 2011/09/28 22:29:45, apatrick_chromium wrote:

[apatrick_chromium, 2011/10/07 22:45:49]

Yeah that's the one. Sorry about that.

 """
 
 # This is the list of all commmands that will be generated and their Id.
@@ -431,6 +432,7 @@ _CMD_ID_TABLE = {
   'Placeholder453CHROMIUM':                                    453,
   'GetMultipleIntegervCHROMIUM':                               454,
   'GetProgramInfoCHROMIUM':                                    455,
+  'SetSurfaceVisibleCHROMIUM':                                 456,
 }
 
 # This is a list of enum names and their valid values. It is used to map
@@ -1768,6 +1770,13 @@ _FUNCTION_INFO = {
     'extension': True,
     'chromium': True,
   },
+  'SetSurfaceVisibleCHROMIUM': {
+      'type': 'Custom',
+      'impl_func': False,
+      'unit_test': False,
+      'extension': True,
+      'chromium': True,
+  },
 }