Linux: WebGL interactions with libGLESv2.so

[Paweł Hajdan, Jr.]

I have a Gentoo developer's report about WebGL not working in certain circumstances: http://bugs.gentoo.org/show_bug.cgi?id=348841

It seems that the browser behaves differently depending on whether libGLESv2.so is present on the system. This is generally unwanted behavior for Linux distributions.

Do you have some ideas how to solve the issue (WebGL not working when libGLESv2.so is present on the system)?

[James Robinson]

I believe that warning is incorrect (and we should probably remove it).  WebGL runs fine on my ubuntu system with no libGLESv2.so (and prints that error message on startup).

- James

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Evan Martin]

I'm not familiar with this code, but it appears to try different
implementations in sequence:

for (const GLImplementation* p = allowed_implementations_begin;
p < allowed_implementations_end;
++p) {
if (InitializeGLBindings(*p))
break;
}

So the warning prints when you don't have GLES but it tries other
implementations as well.

static const GLImplementation kAllowedGLImplementations[] = {
kGLImplementationDesktopGL,
kGLImplementationEGLGLES2,
kGLImplementationOSMesaGL
};

[Paweł Hajdan, Jr.]

This is tricky, sorry for no warning before. My understanding is that the presence of libGLESv2.so breaks WebGL. See http://bugs.gentoo.org/show_bug.cgi?id=348841#c18

It's also possible that in some configurations it just never works, regardless of whether libGLESv2.so is present or not.

[Zhenyao Mo]

From the error message, it seems that the failure is from ANGLE shader translator initialization.  Pretty weird.

[Antoine Labour]

On Tue, Jan 18, 2011 at 10:13 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

Suggestion 1: don't install drivers that don't work :)

Suggestion 2 (maybe more realistic): add --use-gl=desktop

Antoine

[Kenneth Russell]

On Tue, Jan 18, 2011 at 10:45 AM, Antoine Labour <pi...@google.com> wrote:
>
>
> On Tue, Jan 18, 2011 at 10:13 AM, Paweł Hajdan, Jr.
> <phajd...@chromium.org> wrote:
>>
>> I have a Gentoo developer's report about WebGL not working in certain
>> circumstances: http://bugs.gentoo.org/show_bug.cgi?id=348841
>> It seems that the browser behaves differently depending on
>> whether libGLESv2.so is present on the system. This is generally unwanted
>> behavior for Linux distributions.
>> Do you have some ideas how to solve the issue (WebGL not working when
>> libGLESv2.so is present on the system)?
>
> Suggestion 1: don't install drivers that don't work :)
> Suggestion 2 (maybe more realistic): add --use-gl=desktop

+apatrick

It looks like apatrick fixed this on 1/14 in r71508 by making Chromium
prefer desktop OpenGL over OpenGL ES 2.0 on Linux.

-Ken

[Henry Bridge]

On Tue, Jan 18, 2011 at 10:53 AM, Kenneth Russell <k...@chromium.org> wrote:

On Tue, Jan 18, 2011 at 10:45 AM, Antoine Labour <pi...@google.com> wrote:
>
>
> On Tue, Jan 18, 2011 at 10:13 AM, Paweł Hajdan, Jr.
> <phajd...@chromium.org> wrote:
>>
>> I have a Gentoo developer's report about WebGL not working in certain
>> circumstances: http://bugs.gentoo.org/show_bug.cgi?id=348841
>> It seems that the browser behaves differently depending on
>> whether libGLESv2.so is present on the system. This is generally unwanted
>> behavior for Linux distributions.
>> Do you have some ideas how to solve the issue (WebGL not working when
>> libGLESv2.so is present on the system)?
>
> Suggestion 1: don't install drivers that don't work :)
> Suggestion 2 (maybe more realistic): add --use-gl=desktop

+apatrick

It looks like apatrick fixed this on 1/14 in r71508 by making Chromium
prefer desktop OpenGL over OpenGL ES 2.0 on Linux.

I think that's fine for now.  Do we have a corresponding --use-gl=es so people can test it with ES if they want?  Longer term, do we know what the failure actually is so we can do a sanity check to see if the ES drivers work if they're available?

 

[Kenneth Russell]

On Wed, Jan 19, 2011 at 10:56 AM, Henry Bridge <hbr...@google.com> wrote:
>
>
> On Tue, Jan 18, 2011 at 10:53 AM, Kenneth Russell <k...@chromium.org> wrote:
>>
>> On Tue, Jan 18, 2011 at 10:45 AM, Antoine Labour <pi...@google.com> wrote:
>> >
>> >
>> > On Tue, Jan 18, 2011 at 10:13 AM, Paweł Hajdan, Jr.
>> > <phajd...@chromium.org> wrote:
>> >>
>> >> I have a Gentoo developer's report about WebGL not working in certain
>> >> circumstances: http://bugs.gentoo.org/show_bug.cgi?id=348841
>> >> It seems that the browser behaves differently depending on
>> >> whether libGLESv2.so is present on the system. This is generally
>> >> unwanted
>> >> behavior for Linux distributions.
>> >> Do you have some ideas how to solve the issue (WebGL not working when
>> >> libGLESv2.so is present on the system)?
>> >
>> > Suggestion 1: don't install drivers that don't work :)
>> > Suggestion 2 (maybe more realistic): add --use-gl=desktop
>>
>> +apatrick
>>
>> It looks like apatrick fixed this on 1/14 in r71508 by making Chromium
>> prefer desktop OpenGL over OpenGL ES 2.0 on Linux.
>>
>
> I think that's fine for now.  Do we have a corresponding --use-gl=es so
> people can test it with ES if they want?

Yes; the command line option is:

--use-gl=egl

> Longer term, do we know what the
> failure actually is so we can do a sanity check to see if the ES drivers
> work if they're available?

I'm not sure based on the logging output. We're failing to allocate or
initialize the ANGLE shader compiler, and there are several failure
paths which return NULL without logging any output. The strange thing
is that we should not be calling OpenGL in those code paths, so it's
difficult to understand how the presence of libGLESv2.so would affect
the code. Also, this code runs successfully on ANGLE, which emulates
EGL and OpenGL ES 2.0, so it wouldn't be the first attempt to run this
code in this configuration.

-Ken

[Henry Bridge]

On Wed, Jan 19, 2011 at 11:26 AM, Kenneth Russell <k...@chromium.org> wrote:

On Wed, Jan 19, 2011 at 10:56 AM, Henry Bridge <hbr...@google.com> wrote:
>
>
> On Tue, Jan 18, 2011 at 10:53 AM, Kenneth Russell <k...@chromium.org> wrote:
>>
>> On Tue, Jan 18, 2011 at 10:45 AM, Antoine Labour <pi...@google.com> wrote:
>> >
>> >
>> > On Tue, Jan 18, 2011 at 10:13 AM, Paweł Hajdan, Jr.
>> > <phajd...@chromium.org> wrote:
>> >>
>> >> I have a Gentoo developer's report about WebGL not working in certain
>> >> circumstances: http://bugs.gentoo.org/show_bug.cgi?id=348841
>> >> It seems that the browser behaves differently depending on
>> >> whether libGLESv2.so is present on the system. This is generally
>> >> unwanted
>> >> behavior for Linux distributions.
>> >> Do you have some ideas how to solve the issue (WebGL not working when
>> >> libGLESv2.so is present on the system)?
>> >
>> > Suggestion 1: don't install drivers that don't work :)
>> > Suggestion 2 (maybe more realistic): add --use-gl=desktop
>>
>> +apatrick
>>
>> It looks like apatrick fixed this on 1/14 in r71508 by making Chromium
>> prefer desktop OpenGL over OpenGL ES 2.0 on Linux.
>>
>
> I think that's fine for now.  Do we have a corresponding --use-gl=es so
> people can test it with ES if they want?

Yes; the command line option is:

--use-gl=egl

ok, but on Windows this will use ANGLE, not for example, the beta 10.7 catalyst drivers, right?  It seems useful to have an explicit flag for this at some point.

[Kenneth Russell]

That's correct. The only way to disable the use of ANGLE on Windows is
to remove the ANGLE DLLs from the Chrome or Chromium installation.

>  It seems useful to have an explicit flag for this
> at some point.

Agreed, for testing purposes at least. Could you file a bug? I am
pretty sure code changes will be needed.

-Ken

>>
>> > Longer term, do we know what the
>> > failure actually is so we can do a sanity check to see if the ES drivers
>> > work if they're available?
>>
>> I'm not sure based on the logging output. We're failing to allocate or
>> initialize the ANGLE shader compiler, and there are several failure
>> paths which return NULL without logging any output. The strange thing
>> is that we should not be calling OpenGL in those code paths, so it's
>> difficult to understand how the presence of libGLESv2.so would affect
>> the code. Also, this code runs successfully on ANGLE, which emulates
>> EGL and OpenGL ES 2.0, so it wouldn't be the first attempt to run this
>> code in this configuration.
>>
>> -Ken
>

[Henry Bridge]

done: 

http://code.google.com/p/chromium/issues/detail?id=70170

Henry