The EGL context creation on X11 now works as expected.

The on-screen (GUI) and off-screen (rendering) context creation works like in the GLX case.

This patch is ready for review.

While this would need some further updating to get all platforms to support EGL, this patch may bring a big additional benefit:
It may finally make headless rendering possible. I.e. allowing our OpenGL renderers (Eevee, Workbench) to be used on render farms. See T54638: OpenGL headless rendering

I don't even know why we still have opengl es backend available since we don't support it.

To me I would remove the ES support.

I reverted some changes and let the commits in the git history to trace these changes and maybe apply them again. Let me know before you merge this so that I can squash the commits.

I am still not sure about eglew. I could only get it running my manually setting at least one function.

As far as I understand, eglewInit is supposed to set all EGL function pointers. But it requires an EGLDisplay which is passed to eglInitialize. This, in turn, requires function eglGetDisplay, whose pointer is not set, since eglewInit hasn't been called yet :-)

1. How is eglew supposed to be used? Can someone point me to a real-world example that used eglew?
2. What is the advantage of eglew over glew+egl? Or why can't Blender use glew+egl instead of eglew?

In D6585#155719, @Christian Rauch (christian.rauch) wrote:

As far as I understand, eglewInit is supposed to set all EGL function pointers. But it requires an EGLDisplay which is passed to eglInitialize. This, in turn, requires function eglGetDisplay, whose pointer is not set, since eglewInit hasn't been called yet :-)

This indeed seems to be a weakness in the eglew API. In the implementation of glewInit() there is this:

getCurrentDisplay = (PFNEGLGETCURRENTDISPLAYPROC) glewGetProcAddress("eglGetCurrentDisplay");
return eglewInit(getCurrentDisplay());

So it seems fine to do the same here. Alternatively we can call glewInit() here so that it initializes both glew and eglew, which if it causes no problems is the easiest solution. But I'm not sure it will work, so probably keeping the code as in this patch will be fine.

In D6585#155719, @Christian Rauch (christian.rauch) wrote:

1. How is eglew supposed to be used? Can someone point me to a real-world example that used eglew?
2. What is the advantage of eglew over glew+egl? Or why can't Blender use glew+egl instead of eglew?

The advantage of using glew and eglew is that the symbols are loaded at runtime, which means that if they are missing Blender does not fail to start.

There may be systems without EGL that we want to run Blender on, either using GLX, or in background mode when we don't need OpenGL at all.

For OpenGL and EGL extensions, it allows us to check at runtime if the functions are available and if not provide some fallback so Blender still works.

So eglew is just EGL and once initialized the function calls work the same way. It just additionally provides a way to check at runtime which version and extensions are available.

In D6585#156084, @Brecht Van Lommel (brecht) wrote:

In D6585#155719, @Christian Rauch (christian.rauch) wrote:

As far as I understand, eglewInit is supposed to set all EGL function pointers. But it requires an EGLDisplay which is passed to eglInitialize. This, in turn, requires function eglGetDisplay, whose pointer is not set, since eglewInit hasn't been called yet :-)

This indeed seems to be a weakness in the eglew API. In the implementation of glewInit() there is this:

getCurrentDisplay = (PFNEGLGETCURRENTDISPLAYPROC) glewGetProcAddress("eglGetCurrentDisplay");
return eglewInit(getCurrentDisplay());

So it seems fine to do the same here. Alternatively we can call glewInit() here so that it initializes both glew and eglew, which if it causes no problems is the easiest solution. But I'm not sure it will work, so probably keeping the code as in this patch will be fine.

Unfortunately, that did not work. This branch inside glewInit is only reached if glewContextInit() returns 0, which it does not in my case.

In D6585#156085, @Brecht Van Lommel (brecht) wrote:

For OpenGL and EGL extensions, it allows us to check at runtime if the functions are available and if not provide some fallback so Blender still works.

Is the only advantage of using elgew instead of glew that you have access variables like EGLEW_VERSION_1_5 to check at runtime of EGL version 1.5 is available?
While this is convenient, you could query the EGL version at runtime via eglInitialize and do these checks.

At the moment, using eglew instead of glew has some maintenance costs for manually defining function pointer like eglGetDisplay and having to call initContextEGLEW at the beginning and again initContextGLEW at the end, to properly initialise an EGL context. This might also be because I am using it in the wrong way, but then there aren't many examples out there that demonstrate how to properly use eglew. I personally, would use glew, since it is widely used and seems to be established, and manually check the EGL version if I have to handle different versions.

In any case, if you are happy with the current eglew workaround, I would be happy if you could review the remaining parts of this PR :-)

Let me know if you are fine with the eglew workaround, so I can squash my commits and rebase.

Is there anything left that has to be addressed by this patch?

In D6585#156223, @Christian Rauch (christian.rauch) wrote:

Is the only advantage of using elgew instead of glew that you have access variables like EGLEW_VERSION_1_5 to check at runtime of EGL version 1.5 is available?
While this is convenient, you could query the EGL version at runtime via eglInitialize and do these checks.

If EGL or any EGL API functions we use are not available, Blender would still fail to start in that case.

The approach with the current workaround is fine for me, it seems pretty much ready except for two minor comments.

I squashed and rebased my branch.
For some reason, arc decided to create a new patch (https://developer.blender.org/D6689) instead of updating this one.

How do I tell arc to push changes on the branch to this review?