Basic How To? Windows Application to use Mesa or GPU-accelerated OpenGL via Conig Op

I’d like to have an option that will select pure software OpenGL via Mesa vs. accelerated OpenGL via the GPU based on a user-chosen configuration option.

We currently use GLEW to access/control OpenGL as well as direct calls (e.g., glDrawElements()).

We have had logic to select OpenGL 1.1 as provided by Microsoft vs. a GPU-accelerated context, but the Microsoft OpenGL just is too stagnant and we can no longer get the results we need.

So essentially, we’d like to have Mesa or GPU-accelerated operation without changing the lion’s share of our existing code. It seems like Mesa could serve as a good replacement for the Microsoft OpenGL 1.1 context, but I don’t quite know how to wire it in so that it can be selected. We will not need both Mesa and accelerated OpenGL simultaneously.

Do you know of a basic overview / how-to available that will point us in the right direction?



Mesa can be compiled for Windose. See here and here. Using Mesa drivers other than the software driver might require quite some work.

A quick google search leads to older precompiled versions or MSVC projects for building older versions. I have never tried to compile Mesa for Windose myself, but from taking a look at the sln files, I guess that it produces an OSMESA32.dll. AFAIK osmesa is the name of the Mesa pure software offscreen rendering platform with its own context creating functions. Switching between that and the regular OpenGL® implementation, requires linking against that library and either using wgl or the osmesa API and somehow tell glew to use the osmesa functions for loading the entry points.

Yes, it’s the “somehow” that I am hoping someone’s already figured out. Thanks.


I’ve compiled Mesa on Windows but it was many years ago (say, 10?) I’ve no idea about recent versions.

From the OP, it looks as though what you want is a setup similar to what id Software used for switching between OpenGL ICDs and 3DFX mini-drivers way back in Quake 2? It’s not a mini-driver you’re using, for sure, but the basic principle will be similar.

The procedure is to not link to opengl32.lib but instead dynamically load OpenGL using LoadLibrary and then retrieve function pointers using GetProcAddress (not wglGetProcAddress). The DLL to load is specified as an argument to your LoadLibrary call, and the guts of the code are available here: - this setup shipped in publicly released commercial programs so you can have some confidence that it works (even though it doesn’t look very pretty).

Alternatively, and if you don’t require runtime switching, you can provide an opengl32.dll which the customer copies into the program directory, and the program will then load that instead of the default system-provided opengl32.dll (the advantage of this is that no coding is required on your part: it “just works”). This is the same kind of setup as is used by GL Intercept so it’s also proven in the field.

How either or both of these work with GLEW, I have no idea, but my suspicion is that the latter will but for the former you’ll need to load everything manually (that may not be such a big deal as it’s just code-grinding and much of it can be automatically generated).

Thanks. LoadLibrary has definitely been on my radar. We use it for some other stuff already so the mechanics of how are clear.

I’m still digging into GLEW to see how it knows what OpenGL implementation to use. Knowing that it already correctly works whether one chooses a Microsoft 1.1 software context or an accelerated context, it really could be as simple as just calling CreateGLEWContext() after creating the rendering context with whichever library we load. Here’s hoping.


This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.