Issue with shared context

[asmaloney]

I've been trying to solve an issue for days now and am hoping someone can point me in the right direction.

Background

I have a QOpenGLWidget which renders using Magnum. Qt is set to share OpenGL contexts:

QCoreApplication::setAttribute( Qt::AA_ShareOpenGLContexts );

I create one static Magnum::Platform::GLContext to be shared.

I am calling (Qt's) makeCurrent & Magnum::GL::Context::current().resetState(ExitExternal) before calling into Magnum code (and EnterExternal on the way out).

The scenes in this case are static (i.e. I create all the objects programatically and they don't change over the lifetime of the widget).

Problem

On macOS this all works fine.

On Windows running on VMWare:

• I open multiple windows each with their own QOpenGLWidget-derived widget
• they all look correct and I can switch between them and interact with them properly
• sometimes (not 100% reproducible) when I close a window (thus deleting the widget), the geometry in another window goes wonky and I start getting:

Debug output: high severity API error (3): GL_INVALID_OPERATION in glBindVertexArray(non-gen name)
Debug output: high severity API error (3): GL_INVALID_OPERATION in glDrawElements

• nothing is crashing, I just get invalid geometry (or sometimes a black window)
• the meshes are created using both Magnum::MeshTools::compile and "manually" using addVertexBuffer and setIndexBuffer and both (sometimes) go wonky

The problem could be with:

• QOpenGLWidget (context sharing getting borked?)
• Magnum (state set/reset problems?)
• my code (not setting things up properly? missed calling something I need to? not understating how this is supposed to work?)
• VMWare (MESA driver bug? context sharing getting borked? Windows ARM on VMWare is buggy? (happens on VMWare on Intel as well))
• something else that's in play that I'm not aware of

and I haven't been able to narrow that down.

Any ideas? Where (and how) should I be looking for the problem here?

Thanks for any insights!

[mosra]

Hi!

The problem with shared GL contexts is that VAOs and FBOs are not shared, for whatever strange reason. It probably made sense back when they designed this functionality with the client/server architecture in mind, but definitely doesn't anymore.

Thus, if you have a GL::Mesh (or a GL::Framebuffer) created in one GL context, you cannot use it in the other context. You can share the buffers (or textures, renderbuffers), but you need to wrap those in a per-context mesh and framebuffer instance. Then it should work, but it's extremely annoying and error prone. The reason why it seems to work on Mac is I assume likely due to their GL driver being built on top of Metal, where I suppose it's easier for them to just reuse Metal's sharing functionality (which I bet has no such exceptions for meshes and framebuffers) in full rather than crippling it to match GL spec. (So the behavior in VMWare (which is Mesa's SVGA3D driver I think) is correct, unfortunately.)

This particular limitation the main reason why I always avoided shared contexts myself. It's possible to render to multiple windows with a single GL context by looping over all windows and for each making it current with a window-specific drawable and drawing there. But it requires extra care when it comes to VSync, as drawing + buffer swap for each window may result in each window waiting for its own VSync and thus the refresh rate going from 60 FPS to 30 to 15, etc. Unfortunately I don't have much experience in this area, and I'm also not sure if Qt allows you to use a single GL context this way.

#321 has some more details and links some code for this approach, it's GLFW however, not Qt.

[asmaloney]

Thanks Vladimír.

The problem with shared GL contexts is that VAOs and FBOs are not shared, for whatever strange reason.

That's fine - I'm not sharing any meshes. I mainly wanted a shared context to avoid recompiling shaders with each instance. Is there another way to achieve that?

Thus, if you have a GL::Mesh (or a GL::Framebuffer) created in one GL context, you cannot use it in the other context.

Unless I'm misunderstanding things, I only ever have one context though. Everything is created while it's activate.

It's almost like when I delete the meshes when closing one window, the vertices/indices of meshes from other windows are getting messed with.

[mosra]

Oh, sorry, I misunderstood, apologies in case I attempted to explain something you already know.

So you're definitely not sharing any meshes, and it still causes these issues? Interesting. That indeed does look like a driver bug, where it could be accidentally deleting VAOs with the same ID from the other shared GL contexts. Heh. Let's assume there are two shared GL contexts:

• You create a mesh in the first GL context, it ends up being VAO with ID 13.
• You create a mesh in the second GL context, it ends up being VAO with ID 13 as well.
• Deleting the VAO 13 in the first GL context then (according to GL spec) shouldn't touch VAO 13 in the other context, but in your case it does, somehow.

Just to rule out some stupid mistake on my end, can you have one Platform::GLContext for each (shared) GL context? I.e., one Platform::GLContext instance for each Qt GL window, and making it current when you render (or touch any GL object from) given window. That's how it should be anyway, because while the GL contexts share objects, they don't share the state of what's currently bound and such. Given that -- according to the errors you have -- it fails during explicit VAO bind, and not elsewhere, the state tracking shouldn't be a culprit, nevertheless having just one state tracker instance for all shared GL contexts is wrong.

Another option to try would be disabling the GL::Extensions::ARB::vertex_array_object extension by passing it to addDisabledExtensions() during Platform::GLContext creation. In case there's indeed a driver bug where deleting a VAO on one context affects VAO with the same ID on other contexts, this could work around it, because with the extension disabled, there's just a single VAO used. But doing this may have some performance implications.

when I close a window (thus deleting the widget), the geometry in another window goes wonky

Oh, hmm, another idea -- couldn't it be that when deleting the widget, some other GL context from a different window is active, and thus you end up deleting completely different VAOs? I'm not sure how Qt works in this case, but I suspect it might not be making the window's GL context current implicitly during a destructor run, and you have to do that yourself.

Maybe this is actually the problem, and it's why it's behaving so random, because it depends on whatever other window got drawn before, and on Qt's internals on different platforms.

[asmaloney]

Thanks - this gives me hope that I'm just doing it wrong!

having just one state tracker instance for all shared GL contexts is wrong

I will start by correcting this. I think I misunderstood the docs:

When you are using multiple OpenGL contexts, each of them needs to have a corresponding Context instance active at the same time, and you need to ensure you only access OpenGL objects that were created by the same context as is currently active.

I probably read this as if "multiple OpenGL contexts" means "not using a shared context", but of course that's not what it's saying.

So every time I want to do anything with GL calls in the widget, I will want to do something like:

QOpenGLWidget::makeCurrent()
Magnum::Platform::GLContext::makeCurrent( &magnumContext );
magnumContext.resetState( Magnum::GL::Context::State::ExitExternal );
// ... do stuff with GL
magnumContext.resetState( Magnum::GL::Context::State::EnterExternal );

If fixing the Magnum contexts doesn't fix the issue I will look at disabling VAOs to see if that is a workaround.

couldn't it be that when deleting the widget, some other GL context from a different window is active

This shouldn't happen because I am calling makeCurrent() in the destructor:

myWidget::~myWidget()
{
   makeCurrent();

   Magnum::GL::Context::current().resetState( Magnum::GL::Context::State::ExitExternal );

   delete mPrivate;  // this holds all the Magnum stuff
   mPrivate = nullptr;
}

[asmaloney]

So I started to change things so I have one Magnum context per widget, but then I don't know how to share the shaders so I only compile them once. They need a context to compile (and destruct), so how do I manage that if each widget has their own Magnum context?

Do I give the shaders their own Magnum context? Would that work because I'm using a shared GL context underneath everything?

[mosra]

This shouldn't happen because I am calling makeCurrent() in the destructor:

Oh. There goes my only hope 😅

I don't know how to share the shaders so I only compile them once.

There's a wrap() API on Magnum GL classes which makes a non-owning wrapper over a "foreign" GL object and then allows it to be used the same way as if it was constructed directly. Unfortunately those are currently not available for shader programs because depending on platform there's quite a lot of of state the shader instance has to track, such as uniform locations, which would need to be subsequently queried in the wrapped instance.

But, given that the context is shared, I think it should be possible to create the shader just once in some context, and then reuse the same instance with different GL contexts (and Platform::GLContext state trackers) active. The state tracker tracks just the GL shader ID so it shouldn't be a problem.

If sharing a single shader instance isn't possible for you, I could attempt to add the wrap() functions, after which it'd be something like this:

// create first window, "owning" and compiling all shaders
window1 = ...;

window2.makeCurrent();
// window1.shader is now from another GL context, query just its ID, the
// (to-be-added) wrap() makes it a state-tracked instance in the current context
window2.shader = Shaders::PhongGL::wrap(window1.shader.id(), ...); 

However, first I'd like to be sure that this path is actually going to fix anything. Could you first try even with the shader instances being duplicated in each widget, to see if it solves the initial problem?

[asmaloney]

Update: So I had to rework a whole bunch of things so I have access to the widget all over the place (ugly - I probably have to rethink my entire architecture), but I think I have it working now with Qt keeping its shared context and using a separate Magnum context for each QOpenGLWidget-derived widget. The code is a lot more fragile now (and probably less perfomant), which I'm not thrilled about, but I don't currently see a way to mitigate that.

In practice this means that nothing is shared between contexts though, so I'll have to look at your wrap feature to see if I can get it working. Is there a way to wrap an entire context at once where it would share all the things that are shareable? Kind of like Qt's setShareContext. Or do I have to call wrap() on each item?

[mosra]

Ah well, the more we dive into this the more it sounds like it'll be a nightmare to maintain... Or, rather, it already is. (The original issue with meshes disappearing is gone with the rework, at least, right?)

Is there really no way to have Qt use a single GL context among all windows, not multiple GL contexts with sharing? Qt docs mention something called Qt::AA_ShareOpenGLContexts, but from the docs alone I can't tell if it's truly a single GL context or if it's the same as the setShareContext() functionality, just exposed differently.

You could test this by querying wglGetCurrentContext() (or cglGetCurrentContext() on Mac) when rendering each window. If it gives back the same pointer / handle every time, then the flag really makes Qt use a single context, everything is a paradise and with this flag you could go back to the original state with a single Platform::GLContext for all windows.

I really hope the flag works, and behaves the same on Mac and on Windows. Otherwise, with multiple GL contexts...:

I'll have to look at your wrap feature to see if I can get it working

My apologies, not sure what was I thinking in that message above. For shaders in particular it's doable in a much simpler way than that, basically just using the same instance with different Platform::GLContext made current. Each time a different Magnum state tracker is used, it'll make sure the shader ID is bound for use if not already, and that's it, there's nothing else that needs to be carried over. Similarly it's possible with textures or buffers, the only exception are meshes / VAOs and framebuffers, as we discussed above. So:

Shaders::PhongGL shader; // constructed with *some* GL context

window1.magnumGLContext.makeCurrent();

shader.draw(window1.mesh);

window2.magnumGLContext.makeCurrent();

shader.draw(window2.mesh);

[asmaloney]

The original issue with meshes disappearing is gone with the rework, at least, right?

Yes! I think everything works now (though it can always use more testing, right?), it's just that nothing is actually shared.

Is there really no way to have Qt use a single GL context among all windows, not multiple GL contexts with sharing?

It doesn't look like it. QOpenGLWidget doesn't allow setting the context; it only provides setShareContext.

Qt::AA_ShareOpenGLContexts (which I have been using—see initial question) does not look like it uses one context either. I checked with your recommended test and got back different pointers for each widget (on macOS; not sure about Windows).

So given that it works now without Magnum sharing, I should be able to go back to using a singleton for my shaders/textures which initializes them on first use and then just uses them in different contexts (after makeCurrent() of course)? (I'm not sharing any meshes, VAOs, or framebuffers.)

That would at least be an alright middle ground I guess. I'll just have to be super-careful when I do anything that interacts with Magnum! 😄

Thanks Vladimír.

[mosra]

Yes! I think everything works now

Perfect. Rare good news these days 😅

Qt::AA_ShareOpenGLContexts (which I have been using—see initial question) does not look like it uses one context either

Sorry, completely forgot that you mentioned it right at the top already. I'm bad at keeping context these days, heh. What does the flag do then? Is it like setShareContext() being called implicitly or some such?

So given that it works now without Magnum sharing, I should be able to go back to using a singleton for my shaders/textures which initializes them on first use and then just uses them in different contexts

Yes! As long as you makeCurrent() correctly, it should work. (Fingers crossed that it doesn't uncover some fresh new horrors.)

---

A totally tangential question -- how complex is the Qt UI you have? Just to have a rough idea.

[asmaloney]

What does the flag do then? Is it like setShareContext() being called implicitly or some such?

Yes. QOpenGLContext::globalShareContext returns an application-wide shared OpenGL context, which is only available if you set Qt::AA_ShareOpenGLContexts. So it's creating a global context and then whenever an QOpenGLWidget is created, it's automatically sharing it.

As long as you makeCurrent() correctly, it should work.

I decided to release with what I had working and then will revisit trying to make it nicer in the future 😄

how complex is the Qt UI you have?

I will include this in an email I will be sending you...

Thank you!