aboutsummaryrefslogtreecommitdiff
path: root/mesalib/docs/MESA_multithread_makecurrent.spec
blob: 5065c2fc0a351a130e182be950cf7eaef8c725f6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
Name

    MESA_multithread_makecurrent

Name Strings

    GLX_MESA_multithread_makecurrent

Contact

    Eric Anholt (eric@anholt.net)

Status

    Not shipping.

Version

    Last Modified Date:  21 February 2011

Number

    TBD

Dependencies

    OpenGL 1.0 or later is required.
    GLX 1.3 or later is required.

Overview

    The GLX context setup encourages multithreaded applications to
    create a context per thread which each operate on their own
    objects in parallel, and leaves synchronization for write access
    to shared objects up to the application.

    For some applications, maintaining per-thread contexts and
    ensuring that the glFlush happens in one thread before another
    thread starts working on that object is difficult.  For them,
    using the same context across multiple threads and protecting its
    usage with a mutex is both higher performance and easier to
    implement.  This extension gives those applications that option by
    relaxing the context binding requirements.

    This new behavior matches the requirements of AGL, while providing
    a feature not specified in WGL.

IP Status

    Open-source; freely implementable.

Issues

    None.

New Procedures and Functions

    None.

New Tokens

    None.

Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)

    Replace the following sentence from section 2.2 Rendering Contexts:
	In addition, a rendering context can be current for only one
	thread at a time.
    with:
	In addition, an indirect rendering context can be current for
	only one thread at a time.  A direct rendering context may be
	current to multiple threads, with synchronization of access to
	the context thruogh the GL managed by the application through
	mutexes.

Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)

    Replace the following sentence from section 3.3.7 Rendering Contexts:
	If ctx is current to some other thread, then
	glXMakeContextCurrent will generate a BadAccess error.
    with:
	If ctx is an indirect context current to some other thread,
	then glXMakeContextCurrent will generate a BadAccess error.

    Replace the following sentence from section 3.5 Rendering Contexts:
	If ctx is current to some other thread, then
	glXMakeCurrent will generate a BadAccess error.
    with:
	If ctx is an indirect context current to some other thread,
	then glXMakeCurrent will generate a BadAccess error.

GLX Protocol

    None.  The GLX extension only extends to direct rendering contexts.

Errors

    None.

New State

    None.

Issues

    (1) What happens if the app binds a context/drawable in multiple
	threads, then binds a different context/thread in one of them?

    As with binding a new context from the current thread, the old
    context's refcount is reduced and the new context's refcount is
    increased.

    (2) What happens if the app binds a context/drawable in multiple
	threads, then binds None/None in one of them?

    The GLX context is unreferenced from that thread, and the other
    threads retain their GLX context binding.

    (3) What happens if the app binds a context/drawable in 7 threads,
	then destroys the context in one of them?

    As with GLX context destruction previously, the XID is destroyed
    but the context remains usable by threads that have the context
    current.

    (4) What happens if the app binds a new drawable/readable with
        glXMakeCurrent() when it is already bound to another thread?

    The context becomes bound to the new drawable/readable, and
    further rendering in either thread will use the new
    drawable/readable.

    (5) What requirements should be placed on the user managing contexts
        from multiple threads?

    The intention is to allow multithreaded access to the GL at the
    minimal performance cost, so requiring that the GL do general
    synchronization (beyond that already required by context sharing)
    is not an option, and synchronizing of GL's access to the GL
    context between multiple threads is left to the application to do
    across GL calls.  However, it would be unfortunate for a library
    doing multithread_makecurrent to require that other libraries
    share in synchronization for binding of their own contexts, so the
    refcounting of the contexts is required to be threadsafe.

    (6) Does this apply to indirect contexts?

    This was ignored in the initial revision of the spec.  Behavior
    for indirect contexts is left as-is.

Revision History

    20 November 2009 Eric Anholt - initial specification
    22 November 2009 Eric Anholt - added issues from Ian Romanick.
    3 February 2011 Eric Anholt - updated with resolution to issues 1-3
    3 February 2011 Eric Anholt - added issue 4, 5
    21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
    along with glXMakeContextCurrent() for removal.