GLEW 2.0 MX discussion

[BartSiwek]

Hi,

I was setting up the GLEW MX and I found the setup instructions a bit confusing. Namely which threads should create the GLEWContext objects, which should initialize them and exactly when the association with a thread and rendering context is made.

As far as I understand (and what worked for me) is the following:

• Each GLEWContext has to be associated with a rendering context and a thread which will be using it.
• The creation of GLEWContext does nothing more than allocated space for it. It does not associate it with the running thread or with the current rendering context. There can be no current rendering context in fact.
• The association with the rendering context and thread is done by a call to glewInit. This call should be made from the thread that will be using the GLEWContext. Additionally the method glewGetContext() should return the GLEWContext to be initialized and the proper rendering context needs to be active.
• The call to glewInit has to be made for every GLEWContext to be used in the rendering thread (which implies using separate rendering context for each one of them).

Now the last point I find to be disputable since things seem to work if I initialize any one GLEWContext from a rendering thread despite using multiple rendering contexts and multiple GLEWContext.

Overall some or all of this info should be added to documentation to make it more clear.

[nigels-com]

Hi Bart,

Thanks for the feedback. I don't have a clear sense of the relative popularity of MX mode, I know I have not used that myself in recent years. It's good to have an issue open to improve the documentation of this.

• Nigel

[nigels-com]

I'm seriously considering dropping MX support in the next release. In a nutshell the problem is the complexity of support both Core contexts and MX. I don't have a clear sense of the relative deployment of GLEW MX, so any feedback that would help inform this decision would be appreciated.

[nigels-com]

MX support is very likely to be omitted from the upcoming GLEW 2.0.0 release. It's still possible to fix bugs in 1.13.x for MX, if necessary.

[kestrelm]

Hello,

What are the steps moving forwards to deal with multiple OpenGL Contexts ( multiple Windows open scenario ) if MX support is omitted?

I am referring to the usage case on Win64 ( Windows 10 ) where multiple GL Contexts are created for say multiple window applications. On Windows, do you think it is correct to call glewInit() for every context change? This is what somebody mentioned here: http://stackoverflow.com/questions/35683334/call-glewinit-once-for-each-rendering-context-or-exactly-once-for-the-whole-app

Is the above the valid way to go for handling multiple opengl contexts?

[nigels-com]

Indeed, handling multiple OpenGL contexts can be an intricate issue. What I would recommend is choosing the arrangement to be as simple as possible. What I'd recommend is ensuring that multi-window apps are creating compatible contexts. Same GPU, same compatibility or forward-compatible mode, same creation path in the code, if possible. I don't think calling glewInit for each context change is desirable, or even necessary, depending on the circumstances. Obviously this scheme would not be appropriate for multi-threading, anyway.

[kestrelm]

Hello,

Thanks for the reply! From my testing it seems like calling glewInit() repeatedly is not required; the code runs just fine with multiple contexts. I am just a bit nervous about the implications of multiple contexts on Win64. I assume that if it is on the same GPU and all of them are on 3.3 core profile, this should be fine?

It is documented here: https://www.opengl.org/wiki/Load_OpenGL_Functions

Where it states: "In practice, if two contexts come from the same vendor and refer to the same GPU, then the function pointers pulled from one context will work in the other. "

I assume this should be true for most mainstream Windows GL drivers?

[nigels-com]

Yes, that sounds about right. I think you could go to some trouble to create incompatible contexts that have different extensions or compatibility vs forward-compatible. But ordinarily that wouldn't be desirable.

[Qlex42]

Hi,

I'm using the MX support of glew from several year now and I'm very happy about it.
My Win64 applications successfully use mutlicontext in aggressive multithread for texture upload or offscreen rendering. My hardware can have multiple graphics cards using the same driver (same manufacturer) in the same computer.

I'm using shared OpenGL context with same pixel format, same compatibility flags and same extensions. I avoid concurrent use of one context, but each context can work on its thread in concurrency with the other ones.

As other users, I'm quite nervous about the implications of the MX drop support and start considering other binding library like glbinding.

Are you really confident about this change ? Thanks for your concern about this.

[nigels-com]

There is a possibility of doing a 1.13.1 maintenance release which continues some MX support. The difficulty internally was combining forward-compatible context support with MX. It wasn't my preference to leave MX out of GLEW 2.0.0, but it was a pragmatic decision to give it lower priority. I'm happy to engage with MX users and help figure out a way forward. Perhaps we could modernise the ABI using TLS. This kind of approach would break ABI compatibility, and require a migration path for apps from MX to MX 2.0.

Just some thoughts.

--- Nigel

[Qlex42]

Hi Nigel. Thanks for this quick reply.

Do you mean Thread Local Storage for TLS ? Storing global gl functions pointer in a TLS seems a nice approach. But may be problematic when moving an OpenGL context activation from a thread to another. In the case of rendering jobs using a threads pool for instance.

Concerning the ABI, I'm pretty fan of the structured object containing gl function pointers. This object is closely related to its corresponding native OpenGL context object (HGLRC...). It's far away from OpenGL's detractors argument saying that "gl is for GLobals". This "object" orientation is so meaningful for user, helping him understand that gl functions are methods and each call need its related native OpenGL context object activated behind. This also help user understand that he need to provide a concurrent call protection strategy to those objects. Sadly, the non MX version do not benefit from this approach.

ABI break between glew v1 and v2 or MX v1 and v2 seem natural for me. A library name change could let the two version coexist and let user the choice to migrate or not. Of course I understand the maintenance cost here. Re-conciliate the two MX / nonMX ABI may be a way to reduce it.

I'm not a specialist about forward-compatible context, and I do not exactly see the interaction between the MX approach. Here some ideas. I'm glad to discuss about it.

By the way, many thanks for all your work on glew library.

Regards,

[nigels-com]

Over the years I've maintained binary compatibility (for non-MX) for each release of GLEW. It has always been a "bare metal" C-style API, and thought there is room for other projects to do C++ or object-oriented style bindings. Indeed for multi-context and multi-GPU scenarios a more object oriented approach is essential, but I always felt that MX had been bolted onto GLEW, rather than being designed into the scheme as a first class feature. I'm resistant to making GLEW MX the default arrangement primarily for that reason of continued source (and binary) compatibility.

What became clear with implementing core context was that implementing _glewGetExtensionString and _glewGetExtensionEnable and the associated _glewBsearchExtension was a tidy solution, except for supporting MX.

One alternative I've considered is to layer MX strictly on top of vanilla GLEW. A thread comes along, calls glewInit() for a particular context then copies the (relevant) function pointers into a struct for passing around (by reference) in thread pools, and the like. It would also have the advantage of being more suitable for targeting subsets of the API. Possibly this GLEW MX 2.0 would be header-only C++, but could co-exist with single-threaded vanilla GLEW on a primary thread. I find this arrangement preferable in the sense that an MX application would still be binary-compatible with subsequent releases of GLEW (without recompilation). GLEW MX 1.x was clearly (to me anyway) always going have a version-specific struct which would require recompilation for a different or newer release of GLEW MX.

Anyway, just a thought. Now that GLEW 2.0.0 is out the door, I do think it's a good time to discuss MX 2.0 and possible alternatives.

• Nigel

[Qlex42]

Hi Nigel,

Bare metal's principle are very good things for library users. They are self explanatory. C API with ABI compatibility has certainly contributed to Glew's success. I understand that those benefits could not be lost now.

Currently, Glew's users only need to rebuild the library when they want to grant new OpenGL extension access.

To be consistent, I think MX2.0 should rely on same principles. (C API, backward compatible ABI, rebuild to allow forward gl extensions access)

This could probably be done by letting MX2 heap-allocate the structure and let to the client a way to get its size at runtime for potential further structure copy or library updates. To be exhaustive we could also let the client provides allocator and dealocator functions if needed.

I like the idea of MX2.0 is working on top of Glew2.0. This avoid macro-defined compilation code with different ABI and allows unit testing's factorization.

Hoping those ideas can help. Best regards.

[pabs3]

FYI, the library QuesoGLC was using GLEW MX exclusively and can't even build with normal MX support. I've only just discovered the removal of GLEW MX support due to GLEW 2.0 reaching Debian and breaking QuesoGLC, which is used by games like Warzone2100 and Chromium BSU. QuesoGLC has an ancient embedded copy of GLEW with MX support so I can ignore this for now but it would be really great if there were an API compatible way to add MX support for GLEW 2.0 so I can use modern GLEW in QuesoGLC.

http://quesoglc.sourceforge.net/

[pabs3]

In addition, several more packages, including the Google Chrome browser, use GLEW MX and no longer build on Debian. I think I will have to reintroduce the old GLEW to Debian so we can have MX support again.

http://bino3d.org/ http://www.chromium.org/Home http://www.k-3d.org/ http://rss-glx.sourceforge.net

[nigels-com]

One option here is that I'm willing to do a maintenance release of GLEW 1.13 for the purpose of MX. This would not bring them to GLEW 2.0, but continue MX support in some form until a migration path is more broadly agreed and decided.

[pabs3]

Maintenance releases of GLEW 1.13 for the purpose of MX sounds good to me, thanks for being willing to work on that and a migration path.

bye, pabs

http://bonedaddy.net/pabs3/

[nigels-com]

Does QuesoGLC support (or aspire to) modern core OpenGL contexts? It seems harmless to bundle a GLEW 1.13.x for static linking, but the broader issue for Debian is having system wide glew.h which are incompatible. If we rename to glewmx.h does it seem like a reasonable stop-gap?

[nigels-com]

I'm not sure that Chromium still depends on GLEW, can you point to any further information about that?

[pabs3]

I'm not sure what you mean by modern core OpenGL contexts, a link to a good reference on this would be handy and I'd be happy to add support for it if that is needed.

For Debian I've made libglewmx-dev conflict with libglew-dev so you can't depend on or install them both at the same time.

Renaming the headers to include mx in the name when building with MX would be handy to allow removal of the conflict.

In Debian at least, the Chromium source package still build-depends on the glew MX package:

https://packages.debian.org/source/unstable/chromium-browser

[Qlex42]

Hi,

Waiting for GLEW MX2.0 and thanks to @lamogui works: Here a patch proposal for GLEW 1.13 to support core profile forward compatible context.

https://github.com/Qlex42/docgl/commit/ccdeacd042b1651a90111e47c9079ccb73ee482e usage: define GLEW_DLABS_FORWARD_COMPATIBLE_PATCH to use it.

Hoping this can helps.

[lamogui]

@Qlex42 I put a direct link to the file it will be easier for people to patch their own https://github.com/Qlex42/docgl/blob/master/extern/src/GL/glew.c

[coordz]

Having read down this thread I'm a little concerned that GLEW 1.x will diverge from 2.x (bad). Is the plan to reintroduce MX support into 2.x once a good design is found? We operate on multi GPU vendor systems so require per context function entry points on Core and EGL drivers.

[nigels-com]

I see. I still prefer a new MX that wraps GLEW, rather than a 1.x MX branch. I don't see that happening under my own steam this year, but I do intend to further migrate from make/perl to python in the next release.

[nigels-com]

I did a bit of selective merging of mainline (GLEW 2.0) onto a glew-1.13 branch. I'm deciding if there might be a glew-1.13.1 which along with the next GLEW 2.0.

https://github.com/nigels-com/glew/tree/glew-1.13

If anyone could test and confirm for MX usage, that would be helpful.

[IgnaceSaenen]

Hi,

What is the status of MX support for Glew 2.x ?

Unless the effort is minimal to have 2.0 and 1.13.1 in the same code base, I am reluctant to split up code paths for all targets, compilers and platforms. In versions prior to 1.13, some tests with multi-threading (and multi-window apps) required individual calls to glewInit() and the code paths to achieve this are messy. So I would like to keep MX support, but move to the 2.0 interface if possible.

Kind regards

[christopher-w-root]

I would also like to know the status of mx support in GLEW 2.x. I'm particularly interested in GLEW mx with EGL, so it seems the 1.13 mx branch would not suffice.

Any update would be appreciated.

Thanks.

[nigels-com]

Christopher, (and others)

MX is not supported in GLEW 2.x and I'm not aware of any particular effort to bring it back to the mainline. I do sympathise with the downstream consequences, it was not an easy or happy decision on my part, but the pressure for core context support swayed the argument at the time.

On Sourceforge the downloads of 1.13.0 are less than one tenth of those of 2.1.0. That might not all be about MX, but it's only a bit more popular than 2.0.0.

Are there not any alternatives that require a minimum of code porting?

• Nigel

[pabs3]

FTR the current status of GLEW MX usage in Debian is:

• QuesoGLC git master supports non-MX GLEW but I need to do the work to fix it up and release it
• Chromium still build-depends on libglewmx-dev but doesn't seem to use it (filed Debian#941050)
• The Debian package of Gem builds against GLEW MX but it also appears to support non-MX GLEW (filed Debian#941053)

[cblc]

Sorry to bump this old issue, but, does this mean that GLEW cannot work in apps with several OpenGL contexts? I've never used GLEW before, and the documentation doesn't talk about this topic, which is fundamental to me. The way I've always done this (without GLEW) is with one pointer table per context. If you want to be 100% compliant with the standard and the specs, each context can potentially have different function pointers. Is this not supported by GLEW?

[nigels-com]

The idea of GLEW MX is to support multiple OpenGL implementations. GPU driver, and software rendering, for example. GLEW MX isn't usually necessary to support multiple contexts, I would assume that is being done widely. But that does assume that the contexts are compatible-enough to use the same function pointers. I don't recall the specifics of why MX support was dropped, I think it's discussed here somewhere if that's of interest. I had hoped that some other GLEW-like library would take care of that niche, possibly that is now so. Rightly or wrongly GLEW has focused on backwards compatibility and completeness. It's fair to say that limitations like this are pretty well baked-into GLEW, and I think it's a job for alternatives to do it "better", by some definition of "better".