New issue
Advanced search Search tips

Issue 785220 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-03-24
OS: Linux
Pri: 2
Type: Bug-Regression

Blocking:
issue 726075



Sign in to add a comment

Asus Tinker Board lost WebGL support in m62

Reported by a...@scirra.com, Nov 15 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
1. Get an Asus Tinker Board. It's a Raspberry-Pi like board, but with more powerful hardware.
2. Install the stock Debian image which comes with Chromium 57.
3. Check chrome://gpu and verify WebGL works with reasonably good performance web content.
4. sudo apt-get update, then upgrade. Chromium updates to 62.
5. Check chrome://gpu and WebGL content again.

What is the expected behavior?
chrome://gpu should list the same things as hardware-accelerated in M62 as was in m57, and WebGL content should work with reasonably good performance.

What went wrong?
After updating to M62, all GPU features are software only or unavailable, and canvas.getContext("webgl") returns null, so WebGL content falls back to "WebGL not supported" content.

Did this work before? Yes 57.0.2987.98

Does this work in other browsers? N/A

Chrome version: 62.0.3202.89  Channel: stable
OS Version: Debian 9.2
Flash Version: 

I've attached the chrome://gpu pages from M57 and M62. The M62 page lists the following error:

[16309:16309:1115/112145.348718:ERROR:gl_implementation.cc(241)] : Failed to load /usr/lib/chromium/libGLESv2.so: /usr/lib/chromium/libGLESv2.so: cannot open shared object file: No such file or directory
 
asus tinkerboard gpu.zip
9.1 KB Download

Comment 1 by a...@scirra.com, Nov 15 2017

In  issue 719213  I was asked to CC geofflang@chromium.org for this report, but I don't have permission to do that.

Comment 2 by zmo@chromium.org, Nov 15 2017

Cc: geoffl...@chromium.org
Geoff, is this a potential Chrome/ANGLE issue or a Chromium packaging issue?

Comment 3 by kbr@chromium.org, Nov 15 2017

Blocking: 726075
Cc: sugoi@chromium.org julien.isorce@chromium.org
I think this is the same problem fixed by 7a1443f8a4606ba302c36f380415c098259fa6c3 in  Issue 726075 . Can you try a more recent version of Chromium (i.e., version 64) and see whether it works?

Comment 4 by a...@scirra.com, Nov 16 2017

The Tinker Board uses an ARM chip. I can't find a Chrome dev channel for Linux on ARM, the website just points me at the amd64 build. Is there somewhere else I can look?

Comment 5 by kbr@chromium.org, Nov 16 2017

Labels: -Arch-x86_64 Arch-ARM
Sorry, not sure. It looks like Google doesn't provide ARM binaries on Linux. (I checked https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html linked from http://build.chromium.org and the ARM binaries are all years out of date)

Comment 6 by a...@scirra.com, Nov 17 2017

I can check when the next releases make stable channel, but I guess that will take a while...

Comment 7 by danakj@chromium.org, Nov 17 2017

Labels: Needs-Feedback
Can please you let us know if this is resolved when you have access to an M64 version?

Comment 8 by a...@scirra.com, Nov 20 2017

Yes, I'll keep an eye on it and report back.

I found in a forum post the following commands fix it:
sudo ln -s /usr/lib/arm-linux-gnueabihf/libGLESv2.so /usr/lib/chromium/libGLESv2.so
sudo ln -s /usr/lib/arm-linux-gnueabihf/libEGL.so /usr/lib/chromium/libEGL.so

Obviously a hack but works for the mean time, and when M64 is out I'll start from a fresh image and test again from there.
Project Member

Comment 9 by sheriffbot@chromium.org, Nov 20 2017

Cc: danakj@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "danakj@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
Ok thanks

Comment 11 by zmo@chromium.org, Dec 1 2017

That ln trick means you switch to use Chrome's software renderer (SwiftShader) instead of the real GPU (I think, sugoi@ can confirm). You will get a much less performed WebGL because of that.
NextAction: 2018-03-24
ash: M64 and now M65 were release. Does this still occur?

Comment 13 by a...@scirra.com, Mar 9 2018

I can't tell because the latest armhf Chromium build is still m63: https://packages.debian.org/stretch/chromium
Project Member

Comment 14 by sheriffbot@chromium.org, Mar 9 2018

Labels: -Needs-Feedback
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
Labels: Needs-Feedback
Do you know if your dynamic linker configuration is correct? Can other applications find EGL/GL libraries? Can you run ldconfig -p | grep libEGL (and libGLESv2) and let us know the output?
The NextAction date has arrived: 2018-03-24
Status: WontFix (was: Unconfirmed)
As there is no action on this issue for long time closing this issue. Request you to update your Chrome to latest #66.0.3359.181 and verify. Feel free to file a new issue if the issue is still reproduced at your end.

Thanks!

Sign in to add a comment