KhronosGroup / KhronosGroup/OpenGL-Registry

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

Open
#374 3 comments 0 reactions 1 assignee Claimed by @nwnk View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.