8329820: [Linux] Prefer EGL over GLX

[tsayao]

Wayland implementation will require EGL.

EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag prism.es2.forceGLX=true is available.

See:
Switching the Linux graphics stack from GLX to EGL
Prefer EGL to GLX for the GL support on X11

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (3 reviews required, with at least 1 Reviewer, 2 Authors)

Issue

• JDK-8329820: [Linux] Prefer EGL over GLX (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381
$ git checkout pull/1381

Update a local copy of the PR:
$ git checkout pull/1381
$ git pull https://git.openjdk.org/jfx.git pull/1381/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1381

View PR using the GUI difftool:
$ git pr show -t 1381

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1381.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back tsayao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@tsayao this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout egl
git fetch https://git.openjdk.org/jfx.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[lukostyra]

I took a brief look at your changes and I shared some comments.

Overall the changes look good. The EGL/GLX loading in GLFactory feels a bit hacky, but other than making EGL a completely separate Prism backend (which would duplicate/reorganize a lot of common EGL/GLX code - definitely a no-go IMO) I don't have a better idea how to solve this. Maybe with an ES2-specific property like prism.es2.forceglx=true?

This brings me to a question - other than some form of debugging/fallback for when EGL is still new to JFX, do we even need GLX implementation when we have a working EGL implementation? I'm fairly sure that current distros (especially ones officially supported by JFX) have EGL support available at this point in time, and since it's an intermediary layer between application and runtime it shouldn't depend on used GPU.

[lukostyra]

Also a side note - the PR title does not match the JBS issue.

[mlbridge]

Webrevs

• 12: Full (7bdd2963)
• 11: Full (d904e8c4)
• 10: Full - Incremental (47985493)
• 09: Full (51c35579)
• 08: Full - Incremental (8618dd77)
• 07: Full - Incremental (619ae9c4)
• 06: Full - Incremental (0c78b749)
• 05: Full - Incremental (f8c61efc)
• 04: Full - Incremental (4d62744a)
• 03: Full - Incremental (aa321efb)
• 02: Full - Incremental (30203eab)
• 01: Full - Incremental (7ae1f275)
• 00: Full (e8330501)

[kevinrushforth]

This will need a fair bit of testing and review. I would like a chance to review it, but won't be able to get to it for a couple weeks.

Reviewers: @kevinrushforth @lukostyra @johanvos @arapte
/reviewers 3

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 3 (with at least 1 Reviewer, 2 Authors).

[tsayao]

I have to figure out how to test Monocle, since I have changed the logic of defines on PrismES2Defs.h.

[lukostyra]

I left a few comments, mostly for adjusting error-checking. Once those are fixed and others have their input I'll test those changes.

[tsayao]

I changed it to use EGL_DEFAULT_DISPLAY in an attempt to make no assumptions on the platform. It works, but I'm not sure if it's correct. I'm looking at Mesa egl source to be sure.

I also changed the dummy window to use PBUFFER (also to make no assumptions on the platform, so there's no need to create a XWindow). I'm also not sure about that.

[tsayao]

It is possible to set the platform with EGL_PLATFORM=x11 environment variable.
Using EGL_LOG_LEVEL=debug currently outputs that the platform was detected in build time - I think it's wrong.

[tsayao]

I'll have to fix it

I got a reply explaining it (the docs where not very clear)
https://lists.freedesktop.org/archives/mesa-users/2024-April/001727.html

[tsayao]

I changed it to use platform specific way to get EGLDisplay so eglGetDisplay does not have to guess the platform (it can guess wrong).

It can be seen by setting EGL_LOG_LEVEL=debug (with eglGetDisplay it will output the guessing part).

I also reverted the Dummy window code change.

[openjdk]

@tsayao Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[tsayao]

Reopening so maybe it could be usefult to 8332108

[tsayao]

Testing 8332108 with this branch seems to have a significance in favor of EGL:

Using this branch, compare the attached example with and without -Dprism.es2.forceGLX=true

[tsayao]

It seems to make a difference when display refresh rate is lower (60Hz). With higher refresh (160hz), no difference.

EGL:

GLX: