--disable-gpu doesn't disable the GPU process, it just forces the software backend.

The GPU process is critical in the design of chromium. It is unclear why you require not for it to run.

> --disable-gpu doesn't disable the GPU process, it just forces the software backend.

It used to.

In electron 2 which uses chromium 61.0.3163.100, no gpu process was started at all with --disable-gpu

In electron 3 which uses chromium 66.0.3359.181, 1 gpu process is started and immediately exits.

electron 4 behaves the same as described here.

Launching (and keeping around) processes that are not needed is a waste of resources.

> The GPU process is critical in the design of chromium.

Surely it's not critical when it's not needed/used? What about the 2nd launch of the gpu process, that exits right away?

> It is unclear why you require not for it to run.

Resource constraints. My scenario involves starting and stopping multiple instances of an electron app on a single vm, so wasting cpu and memory on two unneeded processes per app instance (one of which is kept around) is problematic. 

 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

For the long-lived process, I suspect that this is due to VizDisplayCompositor, which moves the display compositor out of the Browser process and into the GPU process. Even with GPU disabled, we now handle compositing in the GPU process. 

kylechar@ may know if there's a supported/tested way to run Viz in the browser process on Desktop.

The short-lived GPU process is likely our GPU info collection process, which does't seem like it should need to run if GPU is disabled. zmo@ may be able to give insight into whether this is something we can remove.

So as dtapuska said --disable-gpu just forces using software rendering/compositing and doesn't disable the GPU process. Ignoring the short lived GPU info collection process, the longer lived GPU serves at least two purposes with --disable-gpu.

1. We still run SwiftShader for WebGL in the GPU process both with and without VizDisplayCompositor.
2. Only with VizDisplayCompositor enabled we run the display compositor in the GPU process. This feature is ramping up towards 100% in M71 stable and will likely be on by default by M72 stable.

For #1 it's possible we are starting the GPU process just to check if WebGL is usable even if we're not using it currently (or something like that). That would be an unfortunate regression but it's kind of moot since a fix isn't going to be merged back into M71 at this point. By M72 we'll basically always be running the GPU process for the display compositor due to VizDisplayCompositor.

At the moment you can force no GPU process without OOP-D by also disabling SwiftShader, so "./chrome.exe --disable-gpu --disable-software-rasterizer", which will block the GPU process from starting. With VizDisplayCompositor enabled on Linux and Mac we'll still start a GPU process even with that flag. With VizDisplayCompositor enabled on Windows we'll run the display compositor in the browser process instead so the flag will work. Don't rely on this continuing to work with Windows, it's only because we had issues with third party code blocking the GPU process from starting. Ideally we'd run the display compositor in a sandboxed GPU process.

zmo: Does it sound reasonable to not start the GPU info collection process if --disable-gpu is passed in?

> Don't rely on this continuing to work

Please consider continuing to support a mode that minimizes process sprawl.  Besides electron, your own officially supported headless mode would benefit from that. If you are starting multiple headless sessions in a resource constrained environment you want as few processes as possible, ideally just a browser and renderer.

The GPUInfo collection already obeys kDisableGPU. However, collecting DX12/Vulkan supports doesn't.

magchen@: can you change the behavior so that if --disable-gpu is passed in, don't collect DX12/Vulkan supports info?

I will work on it.

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

commit 960c955a632962bdba625f8bb48a1c1a3ce48997
Author: Maggie Chen <magchen@chromium.org>
Date: Fri Jan 04 02:03:36 2019

No DX Diag and DX12/Vulkan Info collection if --disable-gpu is in the command line

The unsandboxed GPU process to run DX Diagnostics and to collect DX12/Vulkan info should
not be launched if "--disable-gpu" is added to the command line switch.

Bug:  916338 
Change-Id: Ib2551902f81e011e746436076b3d10c5848f5b37
Reviewed-on: https://chromium-review.googlesource.com/c/1394990
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#619860}
[modify] https://crrev.com/960c955a632962bdba625f8bb48a1c1a3ce48997/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/960c955a632962bdba625f8bb48a1c1a3ce48997/content/browser/gpu/gpu_data_manager_impl_private.h
[modify] https://crrev.com/960c955a632962bdba625f8bb48a1c1a3ce48997/content/browser/gpu/gpu_process_host.cc

After this fix, the two short-lived GPU processes for GPU info collection in Windows will not start if --disable-gpu is specified.

The long-lived GPU process for display composition remains unchanged.

Actually, both DX12/Vulkan and DX Diag info collection functions share the same short-lived unsandboxed GPU process if they are called at the same time.

Maggie, thanks for the quick fix.

Will we be able to also get rid of the long-lived GPU process if we pass in --disable-gpu --disable-software-rasterizer --disable-features=VizDisplayCompositor?

Yes. Theoretically, it's possible to remove the long-lived GPU process with this configuration. Will this support be beneficial?

I am simply asking. Theoretically in that mode launching GPU process will be a pure waste, so if we still launch it, that's less than optimal.

However, if the purpose is to control process numbers, maybe --in-process-gpu can serve the purpose as well?

Of the flags mentioned here,

--disable-gpu --disable-software-rasterizer --disable-features=VizDisplayCompositor --in-process-gpu

what is the recommended minimal set that will disable the gpu process and be supported for the foreseeable future?

--in-process-gpu will disable all gpu processes. It should work as expected with the latest code.

What is the effect of disable-software-rasterizer added to disable-gpu? Does that simply disable webgl? Or something more?

--disable-software-rasterizer disables SwiftShader.

Traditionally, --disable-gpu disables the hardware GPU access, but GPU process still launches with SwiftShader, our software renderer. Passing in --disable-software-rasterizer will essentially make GPU process useless, therefore it won't launch.

However, with VizDisplayCompositor enabled, GPU process will launch just for display compositor functionalities, with all hardware/software renderers are disabled.

There might be a less imperfection that GPU process launches even when VizDisplayCompositor is also disabled. However, I think VizDisplayCompositor is planned to launch by default everywhere sooner or later, so that imperfection is no big deal.

I think at this point, --in-process-gpu will be your best shot if your purpose is to control process count. (alternatively, --single-process, which could also get rid of renderer process). But keep in mind, any of these command line switches will put Chrome into a mode that most users are not using. Things will be slightly (or dramatically) different and if something breaks, it may take longer to get fixed because it's affecting less (or no) users.

> --disable-software-rasterizer disables SwiftShader

SwiftShader is defined as 

> a high-performance CPU-based implementation of the OpenGL ES and Direct3D 9 graphics APIs

So I still would like to understand, what is the effect of disabling it in addition to disable-gpu? Does that simply disable webgl? Or something more?


 

Yes, you will lose WebGL. Other than that, I don't think there is much difference.