Keep getting invalid option 'MX_GLOBAL'

[ItIsApachee]

Any chosen API on website (https://gen.glad.sh/) keeps throwing error "Invalid option 'MX_GLOBAL'". Mostly tried GLES 3.2, 3.1 with 2 combinations of options: 1) mx, mx global 2) only mx global Not sure if that is the place to report the issue, but this repository seems to be a viable option.

UPD Installed glad from sources as python module, and it also doesn't have --mx-global option. I also tried --mxglobal, since MXGLOBAL is mentioned in files, but with no success.

[Dav1dde]

Oh it should be disabled on the website, not sure why it shows up.

It's currently disabled for glad2 because a few issues came up, it is also somewhat redundant (multiple contexts and a global context). What is your usecase for this? Currently collecting feedback to decide whether I want to support it or fully remove it.

[ItIsApachee]

Well, Dear imgui's (https://github.com/ocornut/imgui) backend for opengl (https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_opengl3.cpp) relies on calls to globally defined gl functions. By default Dear imgui is using its own stripped version of gl3w, however in my use case I need to use my own loader, and force imgui to use the same one. The reason for that is that I am using ANGLE (https://github.com/google/angle), which requires me to load EGL, and GLES manually. I use GLFW (https://github.com/glfw/glfw), which provides me with the level of control I need, but I can't rely on Dear Imgui loader, because I have no gurantee that it would load ANGLE's libEGL.dll. Because of that, for me to use imgui glad must have global context loaded, but that makes using multiple contexts impossible. I considered loading only 1 glad context globally, and using this everywhere, but I was advised against that decision (https://discourse.glfw.org/t/should-i-assume-glfw-loads-egl-library-only-once/2194/2). Using only 1 glad context globally and switching between gles contexts seems like the easiest option without mx global, but it relies on the thread local storage of libEGL.dll, and in my case, it relies on the fact that every context would be created by the same instance of libEGL.dll. There is a way for me to solve this, and it is to create my own imgui backend implementation, which internally uses glad, and its multiple contexts, but in the end my backend would only slightly differ from the original (https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_opengl3.cpp).

[Dav1dde]

Why do you have to replace imgui's gl3w loader with glad? From the looks of it you could be calling imgl3wInit2 with your own loader function that loads from EGL/Angle (e.g. glfwGetProcAddress).

[ItIsApachee]

Why do you have to replace imgui's gl3w loader with glad? From the looks of it you could be calling imgl3wInit2 with your own loader function that loads from EGL/Angle (e.g. glfwGetProcAddress).

The reason for that is that you are not supposed to call it yourself. This function is called by imgl3wInit, which is called by ImGui_ImplOpenGL3_Init, and this function not only loads the context, it also sets up Dear ImGui's internal structure of OpenGL backend. I probably can write my own implementation of ImGui_ImplOpenGL3_Init with adjustments needed, but in essence it is the same as writing my own backend for ImGui. I don't think that is a proper solution to the given problem.

[Dav1dde]

If you need a quick solution, you can clone glad and uncomment these lines: https://github.com/Dav1dde/glad/blob/f237a2bfcec0d9b82b90ec9af4af265c40de7183/glad/generator/c/__init__.py#L222-L226

It should still generate valid code.

But it sounds like an imgui backend that uses a glad context struct would be the sane option, which would also allow you to actually render imgui to multiple windows without constants switches and render from different threads.

[ItIsApachee]

Thanks for providing feedback. It seems like I wouldn't be able to properly utilize multiple threads because of ANGLE's lack of support for multiple threads (I can't really find the exact info on that topic, but everywhere I looked, the only thing I found is that ANGLE might not be able to handle multiple contexts in a general case). So in the end I think I will go for glad without mx option at all.

But it sounds like an imgui backend that uses a glad context struct would be the sane option, which would also allow you to actually render imgui to multiple windows without constants switches and render from different threads.

Well, yeah, that would work. You need to make Dear ImGui thread-safe, by making its contexts thread local (the way to do that is described in imgui.cpp or imgui.h), but that is a valid point.

I'm not sure if that's now I am supposed to close the issue, but in my opinion mx global option can be helpful in similar situations.

[vAnderegg]

My feedback and question fit this issue very well, so I'm putting it here. I have an application that needs Opengl in several processes at the same time. Meaning for example the main process that has the window handle and created the context and a dll. So I got the idea to pass the glcontext from one process to the other. Is this possible or do I have to initialize this glcontext again? Does anyone have experience with this?

[Dav1dde]

My feedback and question fit this issue very well, so I'm putting it here. I have an application that needs Opengl in several processes at the same time. Meaning for example the main process that has the window handle and created the context and a dll. So I got the idea to pass the glcontext from one process to the other. Is this possible or do I have to initialize this glcontext again? Does anyone have experience with this?

This is not related to glad, nor the MX_GLOBAL feature, but the answer is short. You cannot share the GL Context over multiple processes. Since this is not related to glad and I am also not very familiar with sharing the context you're gonna get better help at a place like StackOverflow.