The entire concept of a "utility process" is intended to be an implementation detail of services at this point, so exposing GPU access broadly to all child process types just so you can acquire it from a utility process seems undesirable to me.

I think the right thing to do would be to add a gpu_client capability to the browser manifest which grants access to ui::mojom::Gpu, and then require that capability from content_browser in whatever service you're creating that will consume it.

Maybe I didn't understand this fully, but I thought there are two layers to getting access to a mojo interface.

The first layer is what you mentioned where the targeted service would expose a capability through its manifest file and other services can acquire this capability by adding a "requires" block in its manifest file.

The second layer is for the targeted service to handle the interface binding requests. And currently for ui::mojo::Gpu interface, only requests from Renderer process [1] are being fulfilled.

The other approach would be to do something similar in UtilityProcessHost [2] as well. With this approach, there won't be any impacts to Renderer process. I think that might be a safer approach.

Let me know what you think. Thanks,

[1]: https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_process_host_impl.cc?sq=package:chromium&l=1230
[2]: https://cs.chromium.org/chromium/src/content/browser/utility_process_host.cc?sq=package:chromium

For a start, let's talk about what else needs access to Gpu. Is it a specific service?

Adding to the previous comment, this bug is for addressing the second layer.

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

commit ad845bdc92660537b9b9bcf0720fac8c38869157
Author: Peter Qiu <zqiu@chromium.org>
Date: Wed Jun 06 07:19:35 2018

browser: allow non-Renderer processes to bind to ui::mojo::Gpu interface

Currently, when ui::mojo::Gpu interface is exposed by the Browser process
(kMash feature is not enabled), only the binding requests from the
Renderer processes are being handled.

For certain devices and applications, it is desirable to access the
ui::mojo::Gpu interface from a non-Renderer process, in order for that process
to access video encode/decode accelerators hosted in the GPU process.

This CL will allow other processes to bind to ui::mojom::Gpu interface
hosted by the Browser process (assuming allowed by the manifest), by
also handling ui::mojom::Gpu interface binding requests in
CommonBrowserInterface. The handling for ui::mojom::Gpu interface binding
requests from Renderer processes will stay the same.

Bug: 836874
Test: run content_browsertests
Change-Id: Ib1e3751d8c593a3c8d29096e7dc9cc609f6a1fa4
Reviewed-on: https://chromium-review.googlesource.com/1028556
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Peter Qiu <zqiu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#564814}
[modify] https://crrev.com/ad845bdc92660537b9b9bcf0720fac8c38869157/content/browser/service_manager/common_browser_interfaces.cc
[modify] https://crrev.com/ad845bdc92660537b9b9bcf0720fac8c38869157/content/public/app/mojo/content_browser_manifest.json