Provide task runner to GLES2Impl / CommandBuffer at creation

Provide task runner to GLES2Impl / CommandBuffer at creation

Currently, GLES2Impl doesn't have a task runner and various
CommandBuffers are inconsistent in how they create/receive one.

In a future change, GLES2Impl will need its own task runner. Ideally,
GLES2Impl and the various CommandBuffers would share this task runner.

This change prepares for this shared usage by always creating a shared
task runner externally and passing it to GLES2Impl and any relevant
CommandBuffer.

In some cases (Android Webview, EGL conform, ppapi), the CommandBuffer
does not currently use a task runner. In these cases we just pass null
to GLES2Impl as well, indicating that it should run any tasks inline on
the current thread.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

[ericrk, 2016-08-24 22:54:41]

Description was changed from

==========
Provide task runner to GLES2Impl / CommandBuffer at creation

Currently, GLES2Impl doesn't have a task runner and various
CommandBuffers create their own or receive one at initialization.

In a future change, GLES2Impl will need its own task runner. Ideally,
GLES2Impl and the various CommandBuffers would share this task runner.

This change prepares for this by always creating this shared task runner
externally and passing it to GLES2Impl and the relevant CommandBuffer.

In some cases (Android Webview, EGL conform, ppapi), the CommandBuffer
does not currently use a task runner. In these cases we just pass null
to GLES2Impl as well, indicating that it should run any tasks inline on
the current thread.

BUG=
==========

to

==========
Provide task runner to GLES2Impl / CommandBuffer at creation

Currently, GLES2Impl doesn't have a task runner and various
CommandBuffers create their own or receive one at initialization.

In a future change, GLES2Impl will need its own task runner. Ideally,
GLES2Impl and the various CommandBuffers would share this task runner.

This change prepares for this by always creating this shared task runner
externally and passing it to GLES2Impl and the relevant CommandBuffer.

In some cases (Android Webview, EGL conform, ppapi), the CommandBuffer
does not currently use a task runner. In these cases we just pass null
to GLES2Impl as well, indicating that it should run any tasks inline on
the current thread.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[ericrk, 2016-08-25 00:33:58]

Description was changed from

==========
Provide task runner to GLES2Impl / CommandBuffer at creation

Currently, GLES2Impl doesn't have a task runner and various
CommandBuffers create their own or receive one at initialization.

In a future change, GLES2Impl will need its own task runner. Ideally,
GLES2Impl and the various CommandBuffers would share this task runner.

This change prepares for this by always creating this shared task runner
externally and passing it to GLES2Impl and the relevant CommandBuffer.

In some cases (Android Webview, EGL conform, ppapi), the CommandBuffer
does not currently use a task runner. In these cases we just pass null
to GLES2Impl as well, indicating that it should run any tasks inline on
the current thread.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Provide task runner to GLES2Impl / CommandBuffer at creation

Currently, GLES2Impl doesn't have a task runner and various
CommandBuffers are inconsistent in how they create/receive one.

In a future change, GLES2Impl will need its own task runner. Ideally,
GLES2Impl and the various CommandBuffers would share this task runner.

This change prepares for this shared usage by always creating a shared
task runner externally and passing it to GLES2Impl and any relevant
CommandBuffer.

In some cases (Android Webview, EGL conform, ppapi), the CommandBuffer
does not currently use a task runner. In these cases we just pass null
to GLES2Impl as well, indicating that it should run any tasks inline on
the current thread.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[ericrk, 2016-08-25 20:49:43]

ericrk@chromium.org changed reviewers:
+ danakj@chromium.org, sievers@chromium.org

[danakj, 2016-08-25 21:03:20]

LGTM, you'll want piman for the ppapi user passing nullptr.

[piman, 2016-08-25 22:51:01]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2016-08-25 22:51:02]

https://codereview.chromium.org/2275113002/diff/60001/gpu/command_buffer/clie...
File gpu/command_buffer/client/gles2_implementation.cc (right):

https://codereview.chromium.org/2275113002/diff/60001/gpu/command_buffer/clie...
gpu/command_buffer/client/gles2_implementation.cc:137:
scoped_refptr<base::SingleThreadTaskRunner> task_runner)
In what way is this task runner meant to be used? I see 2 problems:
1- GLES2Implementation is used in contexts where there is no task runner on the
client thread. For example on the worker thread, as well as in the EGL
implementation for conformance tests and for skia tests.
2- we use the GLES2Implementation on multiple threads, with a lock. This
requires that any task that will use the GLES2Implementation holds the lock
while doing so. So, the client is required to hold that lock when making calls,
and the CommandBufferProxyImpl also takes the lock when executing posted tasks
which would call into the GLES2Implementation - see
CommandBufferProxyImpl::SetLock and uses of that lock. If the
GLES2Implementation is going to post tasks, it will need to take that lock in
those posted tasks, so it will need to be made aware of it.