zmo@, piman@:
How realistic would it be in your opinion for us to implement this? Is it not implemented at the moment because it's not needed, or is it regarded as too complex non-goal to do?

Do you have any thought on how this could be done? In terms of high-level strategy of what components should be included?

The amount of different command buffer -related components is quite high. Would you be able to suggest few classes that need to be there or places to look at code that achieves similar thing? Any help would be appreciated.

Our current thinking is that threaded version might be easier to start with. In the integrated version, the library could expose a CHROMIUM EGL extension that the client would use to select the mode of operation. The default would default to current operation, so that the existing tests would work as they work today.
 
The current problem is that lot of the asynchronous versions of command buffer classes are implemented in "content". Linking to these is not that easy, since the current default .gyp/.gn link targets bring in huge amount of code.

A problem related to process -variant of the task is running the separate process. The chromium process launching infrastructure can probably not be used in this scenario, as the code seems to launch the main executable (maybe in this "zygote" mode), where as of course in command_buffer_gles2 mode the executable is not part of the system. Maybe fork could work in limited scenarios, maybe it is too complex.

GLInProcessContext/InProcessCommandBuffer has support for running the service side in a separate thread (and that's the default, actually, if you pass NULL as the service to GLInProcessContext::Create). It doesn't depend on content - see e.g. ui/compositor/test/in_process_context_provider.cc which creates one for tests.

For the out-of-process scenario, TBH it's a lot of work to replicate a bunch of the content infrastructure, I'm not sure it will give you a good bang for buck. A lot of the out-of-process issues also have to do with the sandbox, so you'd need to wire that up too.

That being said, we are refactoring a bunch of the content/ infrastructure (ipc etc.) for gpu to not depend on content - see the bug tree starting at https://bugs.chromium.org/p/chromium/issues/detail?id=586364 .

Currently we are not actively working on the feature, unassigning.