search

KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
697 stars 277 forks source link

Sharing between GLX contexts with different Displays: threat, or menace? #374

Open nwnk opened 4 years ago

nwnk commented 4 years ago

This came up while investigating a possibly unrelated Mesa bug. Consider the manywin demo, in which two windows are drawn to by two (sharing) contexts belonging to different Display connections to the same server - logically, from the server's perspective, to different clients. For direct clients this is a problem, the two Displays may in general point at different servers (and it's not entirely obvious how to decide they don't), and even if they point at the same server they might not be the same screen. Even with all that, if some server-side resources need to be created implicitly for shared objects, whose XID space should they use?

Despite all this, manywin works on llvmpipe, and radeonsi, and I assume nvidia. And given some bug reports I've seen, there exist non-trivial applications for this too.

I think an argument could be made that the GLX spec's definitions of "same screen" and "address space" are wiggly enough that a driver could reasonably refuse this, and require that share contexts at minimum share a Display. I'd be curious to know how hard other implementations try to make this work.

cubanismo commented 4 years ago

In theory this should all work fine in the NV GLX implementation without any dedicated effort. We validate sharing server-side, even for direct rendering. We don't use any X resource management to track resources below the context level. That said, I don't know that we actually test the multiple-X-servers-using-direct-rendering-in-the-same-application case often, or ever, let alone with negative testing of sharing objects between contexts on different X servers.

My impression was that address space was used to explicitly avoid limiting things to one display connection, since just saying "display connection," at least for the indirect rendering case, would probably have been a lot simpler spec-wise. We do jump through hoops in some places to handle multiple display connections to the same server, just not for this particular case. I'm don't have strong opinions on whether we should loosen or clarify this point in the spec, but trying to claim the spec disallows it seems risky if there's evidence of apps in the field relying on it.

nwnk commented 4 years ago

Yeah, I wouldn't want to claim it's disallowed since clearly it's in use. I'd probably be happy with a note that clarifies that different display, including different connection to same display, is among the possible causes of a BadMatch.

pdaniell-nv commented 4 years ago

@nwnk is this something you can propose a PR for?