Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add modern GNU/Linux GLVND OpenGL implementation support. #7562

Closed
wants to merge 1 commit into from

Conversation

vanfanel
Copy link

@vanfanel vanfanel commented May 5, 2024

Modern OpenGL implementation on GNU/Linux uses GLVND instead of the old/legacy X11-only GLX implementation.

Many modern embedded Wayland-based systems don't include or need the X11 libs, so only modern GLVND is supported in those systems.
In a nutshell, graphical GNU/Linux does not equal or imply X11 anymore.

This PR addresses the GLX two problems that arise when building on a GNU/Linux system with a modern GLVND-based OpenGL implementation instead of X11/GLX:
-The OpenGL library is called libOpenGL.so instead of libGL.so
-There is no glxGetProcAddress, function pointers are obtained via dlsym as in the __APPLE__ platform for example.

If GLX is present and there is no modern GLVND implementation, then GLX lib is loaded and used instead, of course. This is not intended to break legacy GLX support at all.

@PathogenDavid
Copy link
Contributor

This file is automatically generated from https://github.com/dearimgui/gl3w_stripped so it'd be ideal if this PR targeted it instead.

@ocornut
Copy link
Owner

ocornut commented May 6, 2024

I would accept it but I think it should ALSO be submitted in the original gl3w repository.

@ocornut
Copy link
Owner

ocornut commented May 6, 2024

Would this recent-ish commit from GL3W repo solve the same problem?
dearimgui/gl3w_stripped@ec62d76

In which case it may be saner to work to get gl3w_stripped up to date with gl3w.

It's not because when skaslev/gl3w@f588a9e was done there wasn't any subsequent work done to lobby/push the same in gl3w, as a result we are in conflict zon

A rebease of gl3w_stripped over gl3w would be good + lobbying to move the template to an external file.

@ocornut
Copy link
Owner

ocornut commented May 7, 2024

I have started refactoring gl3w_stripped to reduce the drift with gl3w. TLDR: it's a mess, but after an hour of manual rebasing I have at least managed to simplify some of the remaining code to avoid an unnecessary extra indent. Also squashed some of our mods to simplify this going further. Ideally we should either move back the template into the main code, either push a gl3w PR to move code to template. It's a little bit made hairier by the fact gl3w output two files while we output two. The sane thing would be to keep the templates separate, and in our version use both template to output a single file. I would really love if someone could help untangle this (I can help direct them + it's relatively easy to confirm "correct" output as the output file can be compared).

Anyhow. After doing this I have merged two commits from recent gl3w, including
skaslev/gl3w@ec62d76
Which I believe does the same as this very PR.
It's merged in two steps as 1) dearimgui/gl3w_stripped@7a7d986 + dearimgui/gl3w_stripped@7e48489, because of #6983

Once running the script this is the change it does to imgui repo:
0d483a1

@vanfanel Can you confirm that the new loader solves your problem?

I believe the logic in #6983, if still useful, should be backported to GL3W as well.

@ocornut ocornut closed this May 7, 2024
@vanfanel
Copy link
Author

vanfanel commented May 9, 2024

@ocornut Of course! Can you point me to an small example I can use to try the latest code with?
I was using SOH/LUS for making this PR, but I would prefer to use a smaller test/example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants