EGL: Use EGL_EXT_platform_base whenever possible
#92663
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
It seems to launch and run ok, however there's still a lot of weird error output, I'm not sure whether it's relevant Opening just the project selectWeirdly, when I run the game, I get an error dialog about vulkan, even though I passed
But it opens successfully when I click ok. running gameverbose log for running gameI'm not sure why there's another command prompt in the middle of the log, I didn't exit til the end. |
|
Hi @sullyj3, thanks for testing! I'm very sure that the issues you're describing here are unrelated to this PR and more of a known issue or existing rough edge. I'll go into detail.
That's related to the PRIME (OpenGL GPU switching) logic. It's annoying but it's definitely not related to the problem you were experiencing.
I don't think the rendering driver choice propagates from the project manager, so I'm pretty sure that it's normal. The popup comes from the X11 backend, as it fails (as it should to fall back) and supposes that there's no good driver (it has just failed loading the X display). I have a pending change that should improve the situation, but time will be short on time for the next month or so due to school.
Godot restarts every time you "change mode" (project manager, editor, game). Your terminal "loses control" after the first reboot but has still access to the output, so stuff interleaves. That's normal too AFAIK. FTR, that's what I'm talking about when I talk about "choice propagation", as most settings get overwritten on each reboot. In fact, if you look at the "last" block of the non-verbose game log, you can see that it indeed starts with Vulkan:
So yeah, we should be fine here :D |
|
Sweet! I am able to launch Godot with every supported rendering driver. I experience pretty much exactly what @sullyj3 has reported. An error message upon launching the editor, as well as upon opening a project for editing, and when running the project. My steps in the log outputs are as follows:
./godot.linuxbsd.editor.x86_64 --rendering-driver opengl3 --verbose./godot.linuxbsd.editor.x86_64 --rendering-driver vulkan --verboseIf I have "Prefer Wayland" enabled in the editor settings, or run the program with At that point, only the error dialog (the one described in the comment two posts up) upon running the project remains. EGL_PLATFORM=wayland ./godot.linuxbsd.editor.x86_64 --rendering-driver opengl3 --display-driver wayland --verbose |
Shoot! Right. I think we can get rid of the crashes there too. Sorry for the confusion. Let's see what I can do... |
|
I have pushed a change which should alleviate the issue. Note that it can crash anyways (that's why the crash handler didn't ring me any bell) and that it will very probably print some weird warnings. The whole PRIME prober is a very, very, very hacky mess, but no better solution has been found until now (#88516 is the best candidate and doesn't to work for some reason). Hopefully this avoids any big delay by minimizing crashes (I wonder if there's a way to disable the crash handler). Please test this new version of the patch and tell me how it goes, thank you for your patience :D |
|
After unsetting |
This avoids any assumption from the driver, which would otherwise select a specific platform and potentially mess up everything, resulting usually in a display server failure.
|
Haven't tested yet, but note that when I tried to update glad last time, we ran into some issues with ANGLE: #90245 (comment) We need to make sure we're doing it right this time. |
akien-mga
changed the title
EGL_EXT_platform_base whenever possible
|
Tested on Fedora 40 with KDE on Wayland with |
|
@MBCX Would you be able to check that this PR doesn't reintroduce #90879, as it also updates the glad-generated files (but only some of them, in a way that seems safer). I wasn't able to reproduce #90879 locally on Fedora so I can't confirm whether this PR would introduce the same issue. Edit: Nevermind, I was testing the wrong branch. I was able to reproduce #90879 with my glad 2.0.6 update, so I can test this PR too with the same config. Edit 2: I confirmed this PR doesn't introduce the same build issue as #90245 did. |
akien-mga
approved these changes
Jun 13, 2024
|
I'm curious what changed, as I didn't apply the changes proposed in #90245 (comment) due to time reasons. As long as it works, I won't complain xD |
|
@Riteo You only updated the egl files, and not the gl ones. Those are the ones which triggered the issue in #90245 as it updates all files generated by glad. Now we have a mismatch of files generated with glad 2.0.4 and files generated with glad 2.0.6, but it doesn't seem to be a big deal. At least for the egl files, the only change is added a new extension. |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #92014.
This avoids any assumption from the driver, which would otherwise select a specific platform and potentially mess up everything, resulting usually in a display server failure.
#92014 (comment)
As usual, what I predicted as a quick fix became a quite intensive reworking of a core part of the EGL driver.
I was quite naive 7 hours ago 😅
I always forget how messy EGL can get. It's nice, but due to the issues it has to solve it becomes messy really fast.
That said, I tried to be as least invasive as possible and account for static EGL, all while being as careful as possible at preserving readability.
Since this driver is used in most platforms, either through ANGLE or natively, some testing would be highly appreciated :D