This bug is also present in 60.0.3088.3

bisect says:

You are probably looking for a change made after 463863 (known good), but no later than 463933 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/23724703cfbba977e4628436698c59bdba5c2b05..6ede719ec9e4a968c5eedafda3be94c210568d81

and that suggests this might be the cause:

https://chromium.googlesource.com/chromium/src/+/d85baf0b71c69bbd181aaefc8a803611e03c8eed

especially with the log messages I see:

Log Messages
[13988:13988:0507/033502.702735:ERROR:gl_implementation.cc(246)] : Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
GpuProcessHostUIShim: The GPU process exited with code 1024.
[13992:13992:0507/033502.746580:ERROR:gl_implementation.cc(246)] : Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
GpuProcessHostUIShim: The GPU process exited with code 1024.
[13996:13996:0507/033502.791774:ERROR:gl_implementation.cc(246)] : Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory

https://bugs.chromium.org/p/chromium/issues/detail?id=716949#c16 may be having the same problem

As per bisect info provided in comment #3 looping @capn for more updates on this issue.

capn@ - Could you please take a look in to it?

Thanks!

Thanks for the detailed analysis, Ivan! It looks like it's indeed closely related to  Issue 716949 . However, there appear to be two conflated issues: WebGL is blacklisted, while maybe it shouldn't (blacklisting WebGL now blacklists the GPU for all purposes, but that's intentional), and secondly it's not finding the SwiftShader libraries.

I'll look into the latter issue. It works fine when I build Chromium myself, but the libraries don't seem to get shipped with the google-chrome-beta package.

I fixed the missing SwiftShader libraries in  Issue 719507 .

That still leaves the wrongful (?) blacklisting to be fixed.

In revision 463863, the last build before SwiftShader is enabled on Linux, my WebGL is:

WebGL: Hardware accelerated

I'm missing these features:

Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Software only, hardware acceleration unavailable
VPx Video Decode: Software only, hardware acceleration unavailable

and the log shows:

Log Messages
[5117:5117:0510/171422.163953:ERROR:sandbox_linux.cc(343)] : InitializeSandbox() called with multiple threads in process gpu-process.

Is that ERROR enough to force the fallback?  AFAIK, I have not had any serious problems with the GPU acceleration.

We just need to add SwiftShader as an exception to blacklist entry #5.

No, I was wrong.  There must be something else that triggered the switching to SwiftShader.

 Issue 717840  has been merged into this issue.

The issue is we switch to SwiftShader too soon.  We have an blacklist entry (#5) for AMD GPUs on Linux, that we want to disable GPU acceleration (therefore, SwiftShader) unless it's newer mesa driver or a bunch of other exceptions. However, before we get to check GL_VERSION string and etc, we already go down the path of turning on SwiftShader, so these exceptions in the blacklist entry never get a chance to take effect.

After many tries and fails for an entire day, I reached the conclusion that a clean solution would be to move SwiftShader decision to the GPU process side.

Here is what I propose:

1) Recalculate GPU blacklist decisions on GPU process startup (Linux only)
2) After that, decide if we want to switch to SwiftShader or not
3) Don't need to overwrite the GPUInfo data with SwiftShader stuff because that will permanently contaminate the local state of a user and even if they upgrade their drivers, they won't be able to switch back to real GPU.  Instead, I think just add a log saying "Now we switch to SwiftShader version=xxx" that will be included in the about:gpu page is sufficient.

Any feedbacks? piman and capn?

Sounds good, and in line with where we want to go moving forward (remove decisions from the browser process)

Thanks for the analysis, zmo. Regarding point 1), why only Linux? It seems to me that we can't make good blacklisting decisions without first collecting vendor, renderer, and version strings from OpenGL.

Regarding 3), I think SwiftShader should be treated as a secondary (or tertiary) GPU. So collecting its info into GPUInfo should be fine, but we need to be able to select the active one.

For 1), so far we never encountered a blacklisting case that requires these strings except for Linux.  (Android also, but we always have these strings on Android because they are collected on browser startup)

For 3), it's OK to collect, but these strings from SwiftShader should never be written to user local state, otherwise they stay forever.

 Issue 727036  has been merged into this issue.

 Issue 730072  has been merged into this issue.

The issue still persists in 60.0.3112.90 (and even in 62.0.3178.0). So is there any progress?

Deleted: gpu.html 53.1 KB

gpu.html 53.1 KB View Download

#20: unfortunately we can't see the original driver version in your about:gpu. Could you please attach the output of "glxinfo"?

Here is the output.

Deleted: glxinfo 101 KB

glxinfo 101 KB View Download

Thanks. It looks like something's wrong in Chrome's GPU info collection or context creation because that's a really new driver (17.1.5) and shouldn't be being blacklisted.

I'm not really sure how to proceed because we'd need to set up a similar machine to debug it, and this is a large task. Is there any chance you can build Chromium yourself?

Also, what happens if you close Chrome and relaunch it from the terminal with the command line argument:

  --use-gl=angle

?

I tried building it myself and succeeded.

--use-gl=angle seems to have no effect. (I tested it with the official build 62.0.3178.0 and with my own build 62.0.3184.0. The chrome://gpu output of my own build is attached.)

Deleted: gpu_use_gl_angle.html 52.9 KB

gpu_use_gl_angle.html 52.9 KB View Download

I am also affected by this and have attached about:gpu for an official build and my own build where I applied a patch that deleted some AMD card blacklisting segments from software_rendering_list.json (does not actually fix the problem where Mesa is blacklisted despite being a version that should fall within the exceptions).

In addition, compiling with enable_swiftshader=false fixes the problem without any patch.

Deleted: chromium-62.0.3178.0_delete_AMD_blacklisting.patch 2.8 KB

chromium-62.0.3178.0_delete_AMD_blacklisting.patch 2.8 KB Download

Deleted: gpu_62.0.3178.0.html 53.9 KB

gpu_62.0.3178.0.html 53.9 KB View Download

Deleted: gpu_62.0.3178.0_patched.html 60.6 KB

gpu_62.0.3178.0_patched.html 60.6 KB View Download

Deleted: glxinfo 27.4 KB

glxinfo 27.4 KB View Download

kbr@ I've looked at the GPU info collection part: no Mesa version-related code was moved from gpu/config to ANGLE. Detection of the Mesa version is done in CollectDriverInfoGL here https://cs.chromium.org/chromium/src/gpu/config/gpu_info_collector_linux.cc?q=gpu_info_coll&sq=package:chromium&l=62 It looks for the version number in all but the last piece of the GL_VERSION string whereas it is "4.5 (Core Profile) Mesa 17.1.5" in the glxinfo provided. Mesa must have changed the GL_VERSION format with the change to a year version number. I'll update Chrome to handle this.

That said in #26 disabling swiftshader support fixes the problem, so it looks like that part isn't resolved yet.

And ... I should have looked at the code more. It's actually correct because it searches from the end. It looks like it might still be a swiftsahder related issue.

I played a little bit with the file "software_rendering_list.json" and noticed that if I add 
        {
          "driver_vendor": ""
        },
to the exceptions in entry 5 (ATI/AMD cards with older drivers in Linux are crash-prone)
and 
        {
          "driver_vendor": "ES",
          "driver_version": {
            "op": ">=",
            "value": "2.0"
          }
        }
to the exceptions in entry 28 (ATI/AMD cards with third-party drivers in Linux are crash-prone), everything works fine.
In the attached file you can see that the driver vendor is recognized as ES. (But using ES in rule 5 doesn't work...)

Deleted: gpu_working.html 57.6 KB

gpu_working.html 57.6 KB View Download

Let me take this.  I am actively working on refactoring the blacklist code. Once it's done, this bug should be fixed.

 Issue 761614  has been merged into this issue.

I just got an Asus Tinker Board (Mali T764 GPU). The initial SD image has Chromium 57, which supports WebGL 2 and performs pretty well. However if I update it to Chromium 62 it no longer supports WebGL, and the error looks similar to one mentioned here (libGLESv2.so: ... no such file or directory). I checked and the file is indeed missing in the Chromium install.

Is this the same issue as this one or should I file another issue?

It's a different bug. Please file a new crbug and CC geofflang@chromium.org on it.

I filed 785220. I don't have permission to change CC though.

Been 7 months now with no hardware acceleration due to incorrect blacklisting. Is this going to be fixed or what?

leebickmtu: Please be respectful. Since you didn't post on this bug before it isn't clear if your issue is the same. Can you post your about:gpu?

zmo@: Is there something else we should do to fix the issue that was reported originally?

I opened an issue in May which was merged into this one. My about:gpu files can be there.   Issue 717840 

In addition to the about:gpu files in the merged  Issue 717840 , which were from v58 (was working) and v59 (problem started). I also just verified the problem still exists in v62 and attached that file here.

Deleted: 62.0.3202.94.pdf 92.2 KB

62.0.3202.94.pdf 92.2 KB Download

Almost there. It's a huge refactoring and CLs were landed/reverted/relanded due to perf issues, etc. Also, I've been distracted from time to time with various P1 security bugs.

That said, I am getting to the last mile.

This should have been fixed.

Which release version is the fix included in so I can test if it solves the issue?

You can test with Canary. On Linux maybe Developer release?

This is Chrome M65.

HW acceleration still disabled on dev release 65.0.3315.3

Can you post the about:gpu page?

Sure

Deleted: 65.0.3315.3.pdf 96.4 KB

65.0.3315.3.pdf 96.4 KB Download

And then with "Override software rendering list" enabled.

Deleted: 65.0.3315.3-force-hw-accel.pdf 114 KB

65.0.3315.3-force-hw-accel.pdf 114 KB Download

Ah, I think I know where the bug is.  Sorry to speak falsely before. I'll get a fix in.

CL should fix the issue: https://chromium-review.googlesource.com/c/chromium/src/+/864891

Ok, just let me know when this hits a Dev build and I will retest. Can't get Canary on Linux.

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

commit f172c7c7e50d9a074146eae93ae6e963426425f0
Author: Zhenyao Mo <zmo@chromium.org>
Date: Sat Jan 20 05:39:01 2018

On GPU startup, don't switch to SwiftShader if blacklist decision isn't final.

On Linux AMD, we have an entry to blacklist all GPU features on AMD GPU, except
for newer drivers on AMD / Mesa drivers etc.

If we fallback to SwiftShader on vendor_id/device_id, then we put all Linux AMD
to SwiftShader unnecessarily.

BUG= 719213 
TEST=linux AMD
R=piman@chromium.org,kbr@chromium.org
TBR=boliu@chromium.org

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: I6e6209931025383272669ee731bd503ccd6b94ba
Reviewed-on: https://chromium-review.googlesource.com/877410
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530757}
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/android_webview/browser/deferred_gpu_command_service.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/content/common/sandbox_init_mac.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/content/test/content_test_suite.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/command_buffer/tests/gl_tests_main.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/config/gpu_util.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/config/gpu_util.h
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/config/gpu_util_unittest.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/gles2_conform_support/egl/thread_state.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/ipc/service/gpu_init.cc
[modify] https://crrev.com/f172c7c7e50d9a074146eae93ae6e963426425f0/gpu/ipc/service/gpu_init.h

This should be fixed. Wait a few days for this CL to land into Developer build.

To make sure, open about:version, and make sure the revision number (the last part of the Revision string) is bigger than #530757. Then that build has this fix.

Issue 803207 has been merged into this issue.