Bug 249125

Created attachment 464004 [details] The webkit://gpu page on Epiphany Technology Preview with WebKitGTK 2.39.2

So I can reproduce this. Both Ephy Tech Preview and my personal jhbuild WebKitGTK no longer support WebGL. And I have the same aforementioned EGL errors: ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl I will investigate soon, but I assume the problem is caused by USE_ANGLE_WEBGL.

Ok, we need to figure out why ANGLE fails to to initialize EGL, because GLContextEGL is not failing. First I would check the error generated by mFnPtrs->initializePtr in FunctionsEGL::initialize(). That can fail with EGL_BAD_DISPLAY or EGL_NOT_INITIALIZED. I would also check where we are creating the context, it could be either GraphicsContextGLGBM::platformInitializeContext() or GraphicsContextGLFallback::platformInitializeContext() although EGL is initialized with the default display and the same parameters in both cases.

Oh! I can repro with MiniBrowser by enabling the sandbox...

(In reply to Carlos Garcia Campos from comment #3) > Ok, we need to figure out why ANGLE fails to to initialize EGL, because > GLContextEGL is not failing. First I would check the error generated by > mFnPtrs->initializePtr in FunctionsEGL::initialize(). That can fail with > EGL_BAD_DISPLAY or EGL_NOT_INITIALIZED. It's 0x3001 EGL_NOT_INITIALIZED, which is not super informative. But I added this not very useful change: diff --git a/Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/egl/FunctionsEGL.cpp b/Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/egl/FunctionsEGL.cpp index d3061b57a2b7..c2fd90cd1991 100644 --- a/Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/egl/FunctionsEGL.cpp +++ b/Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/egl/FunctionsEGL.cpp @@ -174,7 +174,7 @@ FunctionsEGL::~FunctionsEGL() { SafeDelete(mFnPtrs); } - +#include <stdio.h> egl::Error FunctionsEGL::initialize(EGLNativeDisplayType nativeDisplay) { #define ANGLE_GET_PROC_OR_ERROR(MEMBER, NAME) \ @@ -213,7 +213,8 @@ egl::Error FunctionsEGL::initialize(EGLNativeDisplayType nativeDisplay) mEGLDisplay = mFnPtrs->getDisplayPtr(nativeDisplay); if (mEGLDisplay != EGL_NO_DISPLAY) { - if (mFnPtrs->initializePtr(mEGLDisplay, &majorVersion, &minorVersion) != EGL_TRUE) +auto ret = mFnPtrs->initializePtr(mEGLDisplay, &majorVersion, &minorVersion); + if (ret != EGL_TRUE) { return egl::Error(mFnPtrs->getErrorPtr(), "Failed to initialize system egl"); } That change sure looks like it should do nothing, but for whatever reason it changes the behavior of the calling function Display::initialize, which prints a detailed error only if I make that change: ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: EGL >= 1.4 is required So ANGLE thinks the EGL version is too old, but webkit://gpu reports EGL_VERSION is 1.5. > I would also check where we are > creating the context, it could be either > GraphicsContextGLGBM::platformInitializeContext() or > GraphicsContextGLFallback::platformInitializeContext() although EGL is > initialized with the default display and the same parameters in both cases. Mine is happening in GraphicsContextGLGBM::platformInitializeContext.

Michael, can you reproduce with the sandbox disabled?

Nope, I see lots of fish with the sandbox disabled.

Well I tried debugging this today, but didn't get very far. I can see that ANGLE is successfully dlopening libEGL.so.1, so I think it's really calling into mesa and that's where the failure occurs. But I can't easily step into mesa with host gdb because the web process doesn't run a gdbserver instance inside the sandbox. So that's pretty inconvenient. That's as far as I'm going for now. I'll leave this on my to-do list for next year.

Oh, one more thing. It's not just hardware rendering that's failing. mesa's eglInitialize automatically falls back to software rendering, and presumably that fails to initialize too. (I'm looking at eglapi.c.)

I found the problem of eglInitialize. GraphicsContextGLGBM::platformInitializeContext() uses EGL_DEFAULT_DISPLAY and mesa (when built with x11 support) uses x11 as platform for the default display. So, we are always using EGL over xwayland in both GTK and WPE. With the sandbox enabled, we don't bind X11 when displaynis wayland and mesa fails to initialize egl because xcb_connect() fails. See logs: libEGL debug: Native platform type: x11 (build-time configuration) libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: xcb_connect failed libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: xcb_connect failed libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: xcb_connect failed libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl So, we should always pass the native display to EGL_GetPlatformDisplayEXT, to ensure mesa returns wayland platform from _eglNativePlatformDetectNativeDisplay() when called with a wl_display.

(In reply to Carlos Garcia Campos from comment #10) > I found the problem of eglInitialize. > GraphicsContextGLGBM::platformInitializeContext() uses EGL_DEFAULT_DISPLAY > and mesa (when built with x11 support) uses x11 as platform for the default > display. So, we are always using EGL over xwayland in both GTK and WPE. With > the sandbox enabled, we don't bind X11 when displaynis wayland and mesa > fails to initialize egl because xcb_connect() fails. See logs: > > libEGL debug: Native platform type: x11 (build-time configuration) > libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: > xcb_connect failed > > libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: > xcb_connect failed > > libEGL debug: EGL user error 0x3003 (EGL_BAD_ALLOC) in eglInitialize: > xcb_connect failed > > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize > > ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 12289: > Failed to initialize system egl > > So, we should always pass the native display to EGL_GetPlatformDisplayEXT, > to ensure mesa returns wayland platform from > _eglNativePlatformDetectNativeDisplay() when called with a wl_display. No, that's not the right solution, because we are using EGL_PLATFORM_SURFACELESS_MESA as EGL_PLATFORM_ANGLE_NATIVE_PLATFORM_TYPE_ANGLE, so we want mesa to use the surfaceless display not the native one. In that case passing default display to eglGetPlatformDisplayEXT is the right thing. so, this is actually an ANGLE patch and needs to be fixed there.

An ANGLE bug I mean. Žan has a patch to fix it.

*** This bug has been marked as a duplicate of bug 250073 ***