Re: [chromium-dev] chromium's own GL libraries

[Sunny Sachanandani]

bcc: chromium-dev

cc: graphics-dev, cwallez

The libGLESv2 and libEGL are ANGLE's implementation of GL and EGL. These are built as a data dependency of the x11 build here. These are only used when Chrome is run with --use-gl=angle I think but cwallez would know more about this.

On Mon, Mar 13, 2017 at 11:50 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

Please see https://bugs.gentoo.org/show_bug.cgi?id=612454 for context.

Chromium builds the following libraries (among others): libEGL.so, libGLESv2.so, libosmesa.so . These are usually provided by system mesa package, and so packagers are wondering what's different about our copies.

FWIW, the package seemed to work just fine with these files removed, although I didn't test more sophisticated WebGL demos for example.

Some questions for experts (feel free to redirect me to appropriate ML):

1. Are these files supposed to be installed on the system with the browser? "dpkg-query -L google-chrome-stable | grep \\.so" only shows some Widevine shared objects for me. Maybe we should suggest packagers not to ship the GL .so files?

1a. In case the GL .so files should not be installed, why are they built as part of the build process? How can I verify functionality which might depend on them is working correctly?

2. What does the browser expect from the system wrt GL? I found that e.g. on Gentoo osmesa doesn't seem to be the default, but can be depended on. Currently Gentoo Chromium package doesn't do that though.

3. Do you have recommendations for testing GL-related functionality? I used to check obvious things such as about:gpu, but frequently it shows to me most of the functionality is disabled or software-only.

3a. Are there hardware configurations recommended to test this?

3b. May running inside a chroot affect about:gpu results? My tests suggest that to be the case (I could provide you specific results upon request).

Paweł

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAATLsPbmxqKcUqJTPTk1Ptb0Hk0ScTukW2oAry1aAUF298bsAg%40mail.gmail.com.

[Antoine Labour]

On Mon, Mar 13, 2017 at 12:23 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

bcc: chromium-dev

cc: graphics-dev, cwallez

The libGLESv2 and libEGL are ANGLE's implementation of GL and EGL. These are built as a data dependency of the x11 build here. These are only used when Chrome is run with --use-gl=angle I think but cwallez would know more about this.

Right, those libraries are not currently used in the default configuration, but are likely to be used in the future. I believe we don't ship them currently with the official linux Chrome packages. libosmesa.so is used for testing, and libGLESv2/libEGL are used, as Sunny mentions, when explicitly using ANGLE as a backend. Note that ANGLE uses the underlying system GL libraries, so they are not interchangeable.

Thanks,

Antoine

[Corentin Wallez]

Basically what Antoine said. The two ANGLE .so files aren't used yet but will be in the near future. On Linux they are dependencies of Chrome but are not shipped in Stable, only in Beta so we can test on a variety of systems easily. They are used when --use-gl=angle is given as command line arg.

As for Gentoo's issue, they need not include any of these libraries.

1) they need not be present.

1a) they are dependencies of Chrome because they are intended to be shipped with it soon, and it makes bot stuff / dev easier.

2) Chrome doesn't need a GL, but it will use the native one if it can, currently directly, and soon through ANGLE. Also it will soon expect Swiftshader to be present as a software fallback for WebGL.

3) about:gpu is the correct way to test this, unless you want to run heavy things like the WebGL CTS. It should list the reasons why software is used.

3a) the bots configurations are well tested and should use the GPU, at least for WebGL.

3b) it would do that if the user space driver, or their existence are different. They are libGL, libGLX and friends.

[Julien Bouix]

Hello

Coming back on this old thread in case there are new information...

In our application, we're using ChromiumEmbeddeFramework (CEF) which is an overlay of Chromium, our current best so far version is CEF 104. Due to that, on linux, libEGL.so and libGLESv2 .so are part of our application.

That lead to a conflict when another part of the application spawns Firefox which is not compatible (firefox version 102 with driver NVIDIA 470.161.03 ) with the libEGL version coming from Angle, it needs the os version of libEGL.

As explained by Corentin, we have noticed on our distro that these Angle libraries are not loaded when our CEF integration browse webGL sites, it's instead libwayland-egl.so

So we're wondering what are the risks to remove from our runtimeview these 2 libraries .

Does anyone knows if in the future, or on some distributions, it's mandatory to have them in the RTV?
Thanks