[Mesa-dev] Mesa drivers/GLX and fork
James Jones
jajones at nvidia.com
Tue Oct 15 17:55:22 CEST 2013
In case it helps, we have always interpreted the spec as follows:
-Forking duplicates process memory and FDs, including the display
connection and the GLX context client-side state (and GL server state if
direct rendering, but not X server state, such as the context XID), as
messy as that is.
-A context can only be current to one thread of execution at a time
-Therefore, forking with a context current to the forking thread
produces undefined behavior, since that would result in a context
current in more than one process at the same time, and therefore more
than one thread. We try not to crash, but if the application ever calls
into GL, GLX, or EGL again from this new thread, results may vary.
Usually something crashes.
I would like to get some language into the GLX/EGL specs regarding this,
or at the very least define some sort of expected behavior in the new GL
ABI.
The driver-created offload thread is certainly another interesting
wrinkle here. However, I presume if the application was at least
required to call some GLX (or EGL) function after the fork to set up a
current context (As is the case in our interpretation of the spec), that
would provide a good opportunity to re-initialize any driver state like
internal threads?
Thanks,
-James
On 10/15/13 3:45 AM, Christian König wrote:
> Hi Marek,
>
> for the past few days I've been working on solving
> https://bugs.freedesktop.org/show_bug.cgi?id=70123.
>
> The basic problem is that compton forks itself into the background after
> initializing the X server connection and GLX context. What happens now
> is that only comptons main thread get's cloned by the fork, but not any
> background thread created by the radeon winsys to offload the command
> submission (that is common and very well known pthread behaviour).
>
> I'm not 100% sure if comptons behaviour is valid or not and so if we
> should try to fix it or not. On the one hand it should be transparent to
> the application that we created another thread to offload some work from
> the main thread, but on on the other hand dublicating the X connection
> and GLX context with fork just screams for problems.
>
> Any idea what the spec(s) say about this?
>
> Thanks,
> Christian.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
nvpublic
More information about the mesa-dev
mailing list