KhronosGroup / KhronosGroup/OpenGL-Registry
Sharing between GLX contexts with different Displays: threat, or menace?
- Dominant language
- C
- Stars
- 854
- Forks
- 302
- PR merge metrics
- No merged PRs in 30d
Description
This came up while investigating a possibly unrelated Mesa bug. Consider [the manywin demo](https://gitlab.freedesktop.org/mesa/demos/-/blob/master/src/xdemos/manywin.c), 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.