"1." is already supported since https://codereview.chromium.org/1548893004/

"2." Do you mean that when running tests through python src/testing/xvfb.py, which defines DISPLAY=:55, you would still do like "1.", i.e. black list all features except webgl, but here you would select a specific DISPLAY to use, i.e. passing kX11Display=":0" ? Or do you mean real headless using https://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_platform_gbm.txt or chromium/src/gfx::GbmSurfaceless ?

Thanks for the tip about llvmpipe. I think we'll just need to verify that it works in headless mode and add a smoke test to keep it working.

For the second item I was thinking we'd initially use DISPLAY=:1 but avoid opening any windows. Longer term some kind of surfaceless context extension might be a good way to avoid the display server dependency.

Great news for the smoke test. There is another test currently in gpu_process_tests.py.ReadbackWebGLGpuProcessPage.Validate, but it is not real headless, it just fake that it is llvmpipe: --gpu---testing---gl-renderer.

About second item, this work: python testing/xvfb.py ./out/Release/ ./out/Release/chrome --no-sandbox --display=:0 .

Is your second example still using llvmpipe? I was thinking we would make it possible to use GPU hardware without a display server (not event xvfb).

Second example is not using llvmpipe, that is the point. If you want no display server at all, I guess you would need what I mentioned in #1, i.e. initializing your EGLDisplay with gbm/drm directly. Are you sure this is not already possible in Chromium ? I can see a lot of code about it, ex: chromium/src/gfx::GbmSurfaceless .

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

commit ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7
Author: skyostil <skyostil@chromium.org>
Date: Wed Jul 27 14:42:00 2016

headless: Enable GL support by default

Enable GL support by default so that WebGL and GL-based canvas rendering
can be used. GL support can still be disabled to save resources if
necessary.

BUG=617551

Review-Url: https://codereview.chromium.org/2184763002
Cr-Commit-Position: refs/heads/master@{#408121}

[modify] https://crrev.com/ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7/headless/DEPS
[modify] https://crrev.com/ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7/headless/lib/headless_browser_browsertest.cc
[modify] https://crrev.com/ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7/headless/lib/headless_content_main_delegate.cc
[modify] https://crrev.com/ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7/headless/public/headless_browser.cc
[modify] https://crrev.com/ff3c237e3b02f91c9d8c03006c5fc205bd4e05f7/headless/public/headless_browser.h

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

commit ebfd868404015fb9cb48e99484c5521b93286f62
Author: skyostil <skyostil@chromium.org>
Date: Thu Jul 28 18:43:42 2016

headless: Support --use-gl in headless shell

This patch adds support for the --use-gl command line flag in headless
shell and makes sure we build the default osmesa implementation.

BUG=617551

Review-Url: https://codereview.chromium.org/2187353003
Cr-Commit-Position: refs/heads/master@{#408441}

[modify] https://crrev.com/ebfd868404015fb9cb48e99484c5521b93286f62/headless/BUILD.gn
[modify] https://crrev.com/ebfd868404015fb9cb48e99484c5521b93286f62/headless/app/headless_shell.cc
[modify] https://crrev.com/ebfd868404015fb9cb48e99484c5521b93286f62/headless/app/headless_shell_switches.cc
[modify] https://crrev.com/ebfd868404015fb9cb48e99484c5521b93286f62/headless/app/headless_shell_switches.h

We definitely want to do this on top of SwiftShader and not the copy of OSMesa that Chromium uses for testing. The aim is to delete the latter.

Sounds good to me. Is it okay to migrate to SwiftShader already? I did a quick test and things seem to work:

$ headless_shell --screenshot --use-gl=swiftshader https://www.khronos.org/registry/webgl/sdk/demos/google/san-angeles/

Please ask sugoi@ and capn@. I think we need to wait a bit for the SwiftShader sources to be integrated on all platforms.

#11: skyostil@, are you able to confirm that it's running with SwiftShader in that test? --use-gl=swiftshader triggers the download of SwiftShader from the Component Updater, but in my experience it takes a while before it's done activating, and requires restarting the browser (or at least the GPU process). YMMV, and if it works then yeah keep using it.

Looks like I celebrated too soon -- it seems to have silently fallen back to mesa:

https://drive.google.com/open?id=0ByyxMXB38gLDaTI1bzJRc25UTW8

This is a headless build and it doesn't (currently) have the Component Updater. Is there a way to build SwiftShader up-front somehow?

#14: That's indeed Mesa, not SwiftShader.

I have some prebuilt SwiftShader libraries here: https://goo.gl/5MOcdb. Put libEGL.dll and libGLESv2.dll in the same directory as chrome.dll.

Thanks. Headless actually only works on Linux so far, but it seems like I could build some binaries myself using https://github.com/google/swiftshader?

Are there plans to integrate SwiftShader with Chromium's build system?

I added stable Linux builds to the Drive folder: https://goo.gl/5MOcdb. Put libEGL.so.1 and libGLESv2.so.2 in Chrome's lib folder, and launch with --use-gl=swiftshader

And yes, we're in the process of integrating SwiftShader with Chromium:  Issue 630728 

Assigning to Alexis for follow-up to make sure your use case works once the integration is done.

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

commit d99a9664c873fc38e226e33bc92da974fb852da3
Author: Sami Kyostila <skyostil@chromium.org>
Date: Tue Jun 06 10:28:31 2017

headless: Switch from osmesa to SwiftShader

Now that SwiftShader is shipped with Chrome we can start using it to
render GL content in headless mode. This requires a couple of changes:

1. Skip GPU data collection in headless mode since SwiftShader isn't
   considered a software implementation by that code, leading to a
   failure when we try to retrieve information from the window system.

2. Only skip GL initialization in InitializeStaticEGLInternal if we're
   using osmesa. SwiftShader requires initialization like the other
   non-software implementations.

We also fix a bug where any --use-gl flag specified by the user was
overwritten internally.

Note that SwiftShader is currently not supported on macOS, so we will
continue to use the physical GPU in headless mode on that platform
(unlike on other platforms where everything is software rendered).

To disable WebGL support in headless mode from now on, use --disable-gpu
--disable-software-rasterizer.

BUG=617551

Cq-Include-Trybots: 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: I5ef044f7298afe416f56526f42d2c190466b58e9
Reviewed-on: https://chromium-review.googlesource.com/522068
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Alexis Hétu <sugoi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477253}
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/BUILD.gn
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/lib/headless_content_main_delegate.cc
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/lib/headless_web_contents_browsertest.cc
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/public/headless_browser.cc
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/test/headless_browser_test.cc
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/headless/test/headless_browser_test.h
[modify] https://crrev.com/d99a9664c873fc38e226e33bc92da974fb852da3/ui/gl/init/gl_initializer_x11.cc

what does it mean for rendering screenshots, will it consume less mem/cpu usage?

any guides how to use it? is it patch available in unstable release?

SwiftShader should be faster.  I don't know if it's memory footprint is smaller however.  You don't need to do anything special to use it other than use a  version of chrome(ium) with that pacth included.

You can find out which releases any chromium commit is in by copying the hash (in this case d99a9664c873fc38e226e33bc92da974fb852da3) and pasting it into the Find Releases field of https://omahaproxy.appspot.com/ and pressing the find releases button.

https://storage.googleapis.com/chromium-find-releases-static/d99.html#d99a9664c873fc38e226e33bc92da974fb852da3  That commit has landed in 61.0.3123.0.  

We can see from the chromium release calendar that the _estimated_ release date for that going stable is September 12th.  Note that could very easily change if something crops up.
https://www.chromium.org/developers/calendar

Sami, thanks for making this work with the integrated SwiftShader libraries! Anything else still missing before we close this?

There's this failure on Windows which I haven't had time to debug yet:

https://bugs.chromium.org/p/chromium/issues/detail?id=729961

Looks like we're somehow ending up using a zero texture target. Any leads appreciated :)

need to use with --use-gl=swiftshader option or by default already enable the gl?

No need to use any flags -- WebGL in headless is enabled by default on all platforms except Windows (which should get resolved soon).

Appreciated for all the details in this post.

I built the latest master branch version using 'headless.gn' configuration. However, when I run chromium and navigate to 'chrome://gpu' I see that 'Mesa OffScreen' is selected as default renderer.

Then I used '--use-gl=swiftshader' flag to override osmesa:

[1202/231736.098949:ERROR:viz_main_impl.cc(196)] Exiting GPU process due to errors during initialization
[1202/231736.099494:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_gpu from binding interface: device::mojom::PowerMonitor exposed by: device
[1202/231736.100091:ERROR:browser_gpu_channel_host_factory.cc(121)] Failed to launch GPU process.
[1202/231736.100126:ERROR:gpu_process_transport_factory.cc(1009)] Lost UI shared context.
[1202/231736.100598:ERROR:service_manager_context.cc(219)] Attempting to run unsupported native service: /home/mykolas/projects/chromium/src/out/Headless/content_gpu.service

Then I used one more additional flag '--disable-gpu':

[1202/231936.117792:ERROR:gpu_process_transport_factory.cc(1009)] Lost UI shared context.

Thanks for any insights.

I dag a little deeper. Found that it might be some issue running swiftshader on headless ozone.

https://groups.google.com/a/chromium.org/forum/#!msg/ozone-reviews/Dnvt3VkZArY/7dyoYTsWBAAJ

Looks like headless is the only ozone platform when running chrome build with args in 'headless.gn'.

So I was finally able to run WebGL. headless.gn args use osmesa GL lib by default. However, the lib is very old and the renderer is acient too. So here is what I did:
1. I built osmesa using this script: https://github.com/devernay/osmesa-install (you need to change 'disable_shared' (line 534) to create libOSMesa32.so file) (also you will be asked to install few dependencies required for build).
2. Create a 'libosmesa.so' link to 'libOSMesa32.so' next to headless chrome binary

libOSMesa32.so library has modern render engine that will be able to display pages using WebGL good enough :)

and so how to use swiftshader gl in headless mode?

Are there any command line flags to force the use of the hardware GPU in headless mode and avoid SwiftShader?

No, unfortunately hardware GPUs are not currently supported in headless mode. If it's important to you, please star issue 765284 and describe your use case there.

Hi skyostil@, can you check if this works now?

Hi sugoi, it does work for me on Linux Debian with Chrome 69.0.3497.81

Thanks :)