2.42.0 tarball ENABLE_X11_TARGET=ON USE_GBM=OFF In 2.40.x and earlier, WebGL (and later WebGL2) functioned with compositing mode disabled (WEBKIT_DISABLE_COMPOSITING_MODE=1) In 2.42.0, I am finding WebGL/2 is not functioning. get.webgl.org reports that the browser supports WebGL, but it is disabled or unavailable. The get.webgl.org tests worked in 2.40.x and earlier with hardware compositing disabled. If WebGL is no longer working because hardware compositing is disabled, it is effectively a regression, as this worked in previous releases. (I have to disable compositing mode, as I have an older nVIDIA card and driver. I am unable to use GBM for the same reason.) Thanks for your advice and for your excellent work on the GTK port! It is most appreciated.
It works for me, maybe it's because you built with GBM disabled and we left any GBM check by mistake?
Still works for me without GBM.
(In reply to Carlos Garcia Campos from comment #2) > Still works for me without GBM. and with WEBKIT_DISABLE_COMPOSITING_MODE=1 ?
(In reply to Jim Mason from comment #3) > (In reply to Carlos Garcia Campos from comment #2) > > Still works for me without GBM. > > and with WEBKIT_DISABLE_COMPOSITING_MODE=1 ? Yes.
(In reply to Carlos Garcia Campos from comment #4) > (In reply to Jim Mason from comment #3) > > (In reply to Carlos Garcia Campos from comment #2) > > > Still works for me without GBM. > > > > and with WEBKIT_DISABLE_COMPOSITING_MODE=1 ? > > Yes. :thinking-face: Thanks for confirming that it is still supported. I will close this bug and continue investigation in my system. Any suggestion for where to look to chase this down will be appreciated. I already know this: WebGL is built and linked, window.WebGLRenderingContext is present in the JS environment, but Element getContext("webgl") returns null. There is no exception in JS, and no messages in stdout/stderr of the controlling terminal of WebKitWebProcess.
I finally got WebGL/2 working in my environment. I am reopening, as there are two issues which you may wish to address: 1. PlatformDisplay::m_anglePlatform is not set for X11 and !GBM. Code in PlatformDisplayANGLE.cpp refuses to proceed when this is not set. Expected: m_anglePlatform should be initialised for X11 and !GBM to some valid value (e.g., EGL_PLATFORM_X11_KHR) 2. In GraphicsContextGLTextureMapperANGLE.cpp, use of the context attribute EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE (in support of Nicosia) fails with my native driver. Also, the subsequent two calls to setupCurrentTexture fail. (Note, Nicosia works elsewhere in the application; it is only failing here.) The code suggests an alternate texture mapper is possible, as the code reads: #if USE(NICOSIA) ...Nicosia stuff... #else ...alternate implementation... #endif. However, if I set USE_NICOSIA OFF and do a clean build, compilation breaks: unique_ptr.h:962:30: error: invalid new-expression of abstract class type 'WebCore::TextureMapperGCGLPlatformLayer' 962 | { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from webkitgtk-2.42.0/Source/WebCore/platform/graphics/texmap/GraphicsContextGLTextureMapperANGLE.cpp:43: Expected: It should be possible to build with USE_NICOSIA OFF. As well, ideally, the ANGLE code for Nicosia should consider that not all drivers support EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE and whatever is going on in setupCurrentTexture. Thanks for reading and as always for your excellent work on the GTK port!
(In reply to Jim Mason from comment #6) > I finally got WebGL/2 working in my environment. Great!, I guess it worked for me because I was under wayland? > I am reopening, as there > are two issues which you may wish to address: > > 1. PlatformDisplay::m_anglePlatform is not set for X11 and !GBM. Code in > PlatformDisplayANGLE.cpp refuses to proceed when this is not set. > > Expected: m_anglePlatform should be initialised for X11 and !GBM to some > valid value (e.g., EGL_PLATFORM_X11_KHR) > So, was this enough for you to make it work? > 2. In GraphicsContextGLTextureMapperANGLE.cpp, use of the context attribute > EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE (in support of Nicosia) fails with my > native driver. Also, the subsequent two calls to setupCurrentTexture fail. > (Note, Nicosia works elsewhere in the application; it is only failing here.) hmm, how did you make it work then? > The code suggests an alternate texture mapper is possible, as the code > reads: #if USE(NICOSIA) ...Nicosia stuff... #else ...alternate > implementation... #endif. However, if I set USE_NICOSIA OFF and do a clean > build, compilation breaks: Yes, an alternative to nicosia is possible, but not supported by GTK and WPE ports. This code is shared with other ports. There's no public option to build without nicosia. > unique_ptr.h:962:30: error: invalid new-expression of abstract class type > 'WebCore::TextureMapperGCGLPlatformLayer' > 962 | { return unique_ptr<_Tp>(new > _Tp(std::forward<_Args>(__args)...)); } > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from > webkitgtk-2.42.0/Source/WebCore/platform/graphics/texmap/ > GraphicsContextGLTextureMapperANGLE.cpp:43: > > Expected: It should be possible to build with USE_NICOSIA OFF. As well, > ideally, the ANGLE code for Nicosia should consider that not all drivers > support EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE and whatever is going on in > setupCurrentTexture. I don't know how to handle the case of EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE not being supported, I thought that was angle internal thing not depending on the driver. > Thanks for reading and as always for your excellent work on the GTK port!
(In reply to Carlos Garcia Campos from comment #7) > (In reply to Jim Mason from comment #6) > > > Expected: m_anglePlatform should be initialised for X11 and !GBM to some > > valid value (e.g., EGL_PLATFORM_X11_KHR) > > > > So, was this enough for you to make it work? Necessary but not sufficient. A hack to deal with the Nicosia issue was also needed. (For some on X11 with newer native drivers, it might be sufficient.) > > 2. In GraphicsContextGLTextureMapperANGLE.cpp, use of the context attribute > > EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE (in support of Nicosia) fails with my > > native driver. Also, the subsequent two calls to setupCurrentTexture fail. > > (Note, Nicosia works elsewhere in the application; it is only failing here.) > > hmm, how did you make it work then? Commented out that attribute and the two subsequent calls to setupCurrentTexture. This is surely not a solution, but the tanks demo works and looks fine. > I don't know how to handle the case of > EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE not being supported, I thought that > was angle internal thing not depending on the driver. For me, the call to EGL_CreateContext fails if the attribute is set. I did not dig into what ANGLE is doing internally with the attribute. Also, I did not investigate the failures of setupCurrentTexture, as I supposed it was somehow related to the attribute.
(In reply to Jim Mason from comment #8) > For me, the call to EGL_CreateContext fails if the attribute is set. I did > not dig into what ANGLE is doing internally with the attribute. Also, I did > not investigate the failures of setupCurrentTexture, as I supposed it was > somehow related to the attribute. To be clear, in the failure mode, EGL_CreateContext returns EGL_NO_CONTEXT; removing the attribute, EGL_CreateContext succeeds, but then the subsequent calls to setupCurrentTexture raise a segmentation fault and crash WebKitWebProcess. Investigating the crash further, it seems this is not related to the attribute. It happens on the call to glGetIntegerv(GL_TEXTURE_BINDING_2D, &texture) in GraphicsContextGLTextureMapperANGLENicosia.cpp. In that file, if I change #include <epoxy/gl.h> to #include <GL/gl.h> to avoid libepoxy, then the crash is gone and glGetIntegerv returns with a good value (a monotonically increasing integer). libepoxy is normally reliable in my environment, so not sure why it is getting confused here. In any event, I am fine with patching this locally, but you should be aware, at least in my case (X11/NVIDIA), there is an anomaly. This leaves the one remaining issue with EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE. I will investigate in ANGLE further, but in the meantime, what failure modes should I observe with this off? I ran https://registry.khronos.org/webgl/sdk/tests/webgl-conformance-tests.html and even with the virtualization group attribute commented out, I find net fewer conformance test failures with 2.42.0 relative to 2.40.5. Thanks again for your advice.
(In reply to Jim Mason from comment #9) > This leaves the one remaining issue with > EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE. I will investigate in ANGLE > further. I have found ANGLE does not like the context created by GLContext. When it attempts to use this as a shared context in a subsequent call to eglCreateContext(), it fails with 0x3006 EGL_BAD_CONTEXT. The problem is that there are two different EGLDisplays: m_eglDisplay, obtained by PlatformDisplay::initializeEGLDisplay(), and m_angleEGLDisplay which is obtained by PlatformDisplay::angleEGLDisplay(). It seems for most people, these reference the same display, but in my case, they are different. eglCreateContext in ANGLE refuses to use the shared context created by GLContext, as it is on a different display. If I modify the code so that GLContext uses m_angleEGLDisplay instead of m_eglDisplay, it clears the issue. Note the code in PlatformDisplay::initializeEGLDisplay() is using eglGetDisplay(EGL_DEFAULT_DISPLAY) to obtain the display, whilst the code in PlatformDisplay::angleEGLDisplay() uses a variant of eglGetPlatformDisplay, EGL_GetPlatformDisplayEXT. It seems to me the two different ways of obtaining the display ought to be reconciled into one for all egl usage, so that the display is guaranteed to be consistent throughout the code.
(In reply to Jim Mason from comment #10) > (In reply to Jim Mason from comment #9) > > This leaves the one remaining issue with > > EGL_CONTEXT_VIRTUALIZATION_GROUP_ANGLE. I will investigate in ANGLE > > further. > > I have found ANGLE does not like the context created by GLContext. When it > attempts to use this as a shared context in a subsequent call to > eglCreateContext(), it fails with 0x3006 EGL_BAD_CONTEXT. Oh, that's expected, the egl display is expected to be the same. > The problem is that there are two different EGLDisplays: m_eglDisplay, > obtained by PlatformDisplay::initializeEGLDisplay(), and m_angleEGLDisplay > which is obtained by PlatformDisplay::angleEGLDisplay(). It seems for most > people, these reference the same display, but in my case, they are > different. eglCreateContext in ANGLE refuses to use the shared context > created by GLContext, as it is on a different display. If I modify the code > so that GLContext uses m_angleEGLDisplay instead of m_eglDisplay, it clears > the issue. They should be the same. How and where are you initializing m_anglePlatform and m_angleNativeDisplay? > Note the code in PlatformDisplay::initializeEGLDisplay() is using > eglGetDisplay(EGL_DEFAULT_DISPLAY) to obtain the display, whilst the code in > PlatformDisplay::angleEGLDisplay() uses a variant of eglGetPlatformDisplay, > EGL_GetPlatformDisplayEXT. But this is the fallback code, the display should be initialized in PlatformDisplayX11::initializeEGLDisplay() and only if that fails it ends up calling eglGetDisplay(EGL_DEFAULT_DISPLAY). > It seems to me the two different ways of obtaining the display ought to be > reconciled into one for all egl usage, so that the display is guaranteed to > be consistent throughout the code. According to the spec EGL should return the same display for the same combination of platform and native display. That's why we set the angle platform and display when initializing the EGL display in PlatformDisplay (excepty in the X11 case that I forgot). If PlatformDisplayX11::initializeEGLDisplay() is failing, it might still fail, though.
Pull request: https://github.com/WebKit/WebKit/pull/18615
(In reply to Carlos Garcia Campos from comment #12) > Pull request: https://github.com/WebKit/WebKit/pull/18615 I can confirm, this patch resolves the issue in my environment. Thank you!
Committed 268844@main (84145be4284b): <https://commits.webkit.org/268844@main> Reviewed commits have been landed. Closing PR #18615 and removing active labels.