Using ANGLE for OpenGL ES 2.0 project on Linux

[Sagar gv]

Hi,

We have a C project that uses OpenGL ES 2.0. It works fine on Android and in browsers, thanks to Emscripten.

Could you please give some pointers on how to go about using ANGLE to build a native Linux binary?
Also, can ANGLE be used in Android? We found a bug where GL_REPEAT for textures was being ignored on Android. Would ANGLE be able to work around such bugs?

Thanks.

[Corentin Wallez]

Hey Sagar,

We are currently porting ANGLE to work on Linux and Mac and the Linux port is working very well (not tested on all OSS drivers though). In order to use it on Linux, follow the building ANGLE instructions but instead of using Visual Studio use make or ninja to build it. Then simply link your program against ANGLE's libGLESv2.so and libEGL.so (and add some display initialization code).

ANGLE might get ported to Android but this is a longer-term project. We'd definitely try to work around bugs, but I'm not sure exactly we could fix such a core bug.

Let us know if you have more questions,

Corentin

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sagar gv]

Thanks for the quick response. On Ubuntu 14.04, I could build ANGLE's libGLESv2.so and libEGL.so, but there was some error regarding EGL in building the sample projects provided. Anyway, our application seems to work fine with ANGLE on nVidia GPUs. But it crashes with this message on AMD and Intel GPUs:

terminate called after throwing an instance of 'std::logic_error'

  what():  basic_string::_S_construct null not valid

Abort (core dumped)

Incidentally, WebGL worked fine inside Chrome for both these GPUs. Is this a bug in ANGLE or something wrong with my build?

Also, a couple of questions:
- Does ANGLE support Mac OS X? We are exploring MetalGL, but we'd like to support older OS X versions not having Metal. And if ANGLE works, there'll be fewer concerns about incompatibilities.
- For OpenGL ES 2 compliance, what version of Desktop GL does ANGLE need?
- Can ANGLE use the driver OpenGL ES if provided? For instance, nVidia provides it's own libGLESv2.so (which also works for our app). Right now, I'm overriding the default libGLES with rpath=$ORIGIN, but it would be great if ANGLE can detect the presence of libGLESv2.so and decide whether to use it. (Or is ANGLE already doing that with dlopen() which would make the dependency not appear with ldd?)

Thanks,
Sagar

[Geoff Lang]

Hey,

Chrome doesn't use ANGLE on Linux yet which explains why you don't see a crash there.  Can you provide any more information about the crash you saw? Can you try making a debug build and get a stack trace? Driver information would help too so we can try to reproduce it ourselves.

Answering the other questions inline:

- Does ANGLE support Mac OS X? We are exploring MetalGL, but we'd like to support older OS X versions not having Metal. And if ANGLE works, there'll be fewer concerns about incompatibilities.

A: This is currently in progress, cwallez has more knowledge than me but AFAIK we're just missing a bit of work in the EGL layer.

- For OpenGL ES 2 compliance, what version of Desktop GL does ANGLE need?

A: We attempt to work on the lowest driver version possible.  I believe we're able to support ES2 on drivers that support desktop GL 2.0 + framebuffer extensions.

- Can ANGLE use the driver OpenGL ES if provided? For instance, nVidia provides it's own libGLESv2.so (which also works for our app). Right now, I'm overriding the default libGLES with rpath=$ORIGIN, but it would be great if ANGLE can detect the presence of libGLESv2.so and decide whether to use it. (Or is ANGLE already doing that with dlopen() which would make the dependency not appear with ldd?)

A: Supporting loading the native ES drivers is also in progress, expect to see support for that on Linux and Windows in the next month or two.

[Sagar gv]

I'll try it out with the debug build tomorrow when I have physical access to machines with Intel and AMD GPUs. In the meantime, there seems to be an issue running it in Ubuntu 14.04 on VirtualBox (with extensions). EGL context creation is failing. Here is the output of glxinfo:

http://pastebin.com/z5Rdnjjh

And the relevant code:

http://pastebin.com/MJPCfKxi

glxgears works, and the app works in Firefox and Chrome (compiled with Emscripten), albeit with low frame rate. What might be the issue here?

[Corentin Wallez]

On Thu, Nov 5, 2015 at 9:39 AM, 'Geoff Lang' via angleproject <anglep...@googlegroups.com> wrote:

Hey,

Chrome doesn't use ANGLE on Linux yet which explains why you don't see a crash there.  Can you provide any more information about the crash you saw? Can you try making a debug build and get a stack trace? Driver information would help too so we can try to reproduce it ourselves.

Answering the other questions inline:

- Does ANGLE support Mac OS X? We are exploring MetalGL, but we'd like to support older OS X versions not having Metal. And if ANGLE works, there'll be fewer concerns about incompatibilities.

A: This is currently in progress, cwallez has more knowledge than me but AFAIK we're just missing a bit of work in the EGL layer.

The Mac port is working as far as OpenGL goes (up to some driver bugs) however the EGL layer is still very much in flux, and while the current implementation shows stuff on the screen, it will not be usabel before a couple months.

[Corentin Wallez]

The problem with VirtualBox is that it exposes very little GLX capabilities and doesn't have some extensions that we currently require in order to create a context. I have it on my TODO list to support such a low feature level at some point (we'll need it when we turn ANGLE on in Chrome on Linux).

[Sagar gv]

With regard to the crash on Intel and AMD GPUs, the debug build of libGLESv2.so and libEGL.so does not produce a stack trace:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid
Abort (core dumped)

glxinfo from the Intel GPU:

http://pastebin.com/ufqiJSmn

glxinfo on the AMD GPU (with open source driver):

http://pastebin.com/5Z7mCpan

It's possible that I'm ignoring some error value somewhere, and the whole thing becomes train wreck after that, but it looks like at least EGL context creation succeeds in all cases.

After installing proprietary AMD Catalyst drivers, the crash goes away, but the app doesn't seem to wait for V-sync and is running at a very high frame rate. This is the main loop:

    XEvent event;
    while(1)
    {
        while(XPending(x_display))
        {
            XNextEvent(x_display, &event);
            if (event.type == ClientMessage)
            {
                exit(0);
            }
        }
        sampleStateUpdate();
        sampleRender();
        eglSwapBuffers(display, surface);
    }

[Corentin Wallez]

Thanks for the additional info, this makes it seem very much like a problem I ran into when testing on the Intel driver. I expect to re-land a patch today that should fix it.

As for the V-sync not being waited on, it seems it is because Mesa only support the SGI and MESA versions of swap-control. I'll add support for them too.