> 2. Don't start the GPU thread in the GPU process if GPU compositing has crashed multiple times.

Or if the last process told the browser to use software compositing.

I think roughly the logic we want on GPU crash is:

1. Start GPU process and use hardware accelerated compositing. Try three times.
2. Start GPU process. Use software compositing but run SwiftShader on GPU thread for things like WebGL. Try three times.
3. Start GPU process. Use only software compositing. Don't initialize any GL on the GPU thread. Try three times.
4. Crash the browser process.

(1) and (2) happen today. If the GPU process crashes more than tree times after (2) then pure software compositing happens in the browser process and the GPU process isn't needed. This is where things have to change.

GpuProcessHost/GpuDataManager use command line flags to communicate what mode the GPU should start in. I believe it changes --use-gl=swiftshader-webgl flag to switch from hardware acceleration to just SwiftShader for WebGL. There are no flags passed to the GPU process for pure software, because the GPU process isn't run in that configuration yet. We can make (3) happen by passing something like --disable-gpu to the GPU process. 

GpuProcessHost::RecordProcessCrash() keeps track of how many times the GPU has crashed in the current mode and then modifies the mode. We can make (4) happen in GpuProcessHost::RecordProcessCrash() or somewhere similar.

This is a bit more complicated because there is also GpuDataManager (and many subclassses) that store more state about GPU process. If the GPU is blacklisted then GpuDataManager will ensure that we skip mode (1) entirely and never try starting at that point.

> This is a bit more complicated because there is also GpuDataManager (and many subclassses) that store more state about GPU process. If the GPU is blacklisted then GpuDataManager will ensure that we skip mode (1) entirely and never try starting at that point

Note, zmo@ moved virtually all the blacklisting logic to the GPU process, so this is probably less true now. In particular, if the GPU is blacklisted, we fallback to SwiftShader in the GPU process, not in GpuDataManager.

Why we still need a GPU process in scenario 3? It seems to me no GL contexts will be created at all.

> Why we still need a GPU process in scenario 3? It seems to me no GL contexts will be created at all.

Display compositor will be in the "gpu" process for software compositing too, as will all raster.

So right now after SwiftShader crashes three times, GpuDataManagerImplPrivate::swiftshader_disabled_ is set to true, and Gpu process won't launch. We just need to change this logic to still allow GPU process launch, but pass in the swiftshader_disabled_ bit to GpuPreferences, we in next GPU process startup, we can bypass initialize GL bindings etc.

#7 seems like a good starting point. We should have GPU process running (drawing all black because SharedBitmaps aren't being sent to the GPU process) with the following command line:

./chrome --enable-features=VizDisplayCompositor --disable-gpu --disable-software-rasterizer

It DCHECKs now instead of starting the GPU process.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/35c8fbb8481424290a9a4beb028c993f8f40693e

commit 35c8fbb8481424290a9a4beb028c993f8f40693e
Author: Mohsen Izadi <mohsen@chromium.org>
Date: Thu Mar 22 21:48:54 2018

Fix Viz process startup when Viz display compositor is enabled

When Viz display compositor is enabled, Viz/GPU process should always
start up to run display compositor even if there is no GPU hardware
acceleration or SwiftShader enabled. In case display compositor is too
unstable causing Viz process to crash three times, we crash the browser.

We still need to prevent unnecessary GL initialization in the Viz
process when GPU hardware acceleration and SwiftShader are not enabled.
That would happen in a future CL.

BUG= 799478 
TEST=manual

Cq-Include-Trybots: luci.chromium.try:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: Ibf67dc51cbb69f23ec115adb912dfed328ee613f
Reviewed-on: https://chromium-review.googlesource.com/946672
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Commit-Queue: Mohsen Izadi <mohsen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545263}
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/browser_main_loop.cc
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_data_manager_impl.cc
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_data_manager_impl.h
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_data_manager_impl_private.h
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_process_host.cc
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/browser/gpu/gpu_process_host.h
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/content/public/browser/gpu_data_manager.h
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/gpu/config/gpu_util.cc
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/gpu/config/gpu_util.h
[modify] https://crrev.com/35c8fbb8481424290a9a4beb028c993f8f40693e/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b

commit a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b
Author: Mohsen Izadi <mohsen@chromium.org>
Date: Wed Apr 18 18:55:50 2018

Add "disabled" GL implementation

In OOP-D, there are situations that the GPU (Viz) process is run, but no
GL should be initialized (when both hardware acceleration and
SwiftShader are disabled). A new "disabled" value is added to --use-gl
flag to convey this to the GPU process and prevent unnecessary GL
initialization.

BUG= 799478 
TEST=none

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I3a42ab0f72b10e9b2a7b231673ace81adef3847b
Reviewed-on: https://chromium-review.googlesource.com/1014250
Commit-Queue: Mohsen Izadi <mohsen@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551764}
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/gpu/ipc/service/gpu_init.cc
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/gpu/ipc/service/gpu_init.h
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/gl_implementation.cc
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/gl_implementation.h
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/gl_switches.cc
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/gl_switches.h
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/init/gl_factory.cc
[modify] https://crrev.com/a3dd2655825cabc1536ae4ca87a8d54eeff3ba6b/ui/gl/init/gl_factory_android.cc

Now, GPU process always runs when VizDisplayCompositor is enabled and won't initialize GL context if both hardware acceleration and SwiftShader are disabled. Marking as fixed.