blob: 5065c2fc0a351a130e182be950cf7eaef8c725f6 [file] [log] [blame]
Eric Anholt49d7e482011-02-03 17:26:02 -08001Name
2
3 MESA_multithread_makecurrent
4
5Name Strings
6
7 GLX_MESA_multithread_makecurrent
8
9Contact
10
11 Eric Anholt (eric@anholt.net)
12
13Status
14
15 Not shipping.
16
17Version
18
19 Last Modified Date: 21 February 2011
20
21Number
22
23 TBD
24
25Dependencies
26
27 OpenGL 1.0 or later is required.
28 GLX 1.3 or later is required.
29
30Overview
31
32 The GLX context setup encourages multithreaded applications to
33 create a context per thread which each operate on their own
34 objects in parallel, and leaves synchronization for write access
35 to shared objects up to the application.
36
37 For some applications, maintaining per-thread contexts and
38 ensuring that the glFlush happens in one thread before another
39 thread starts working on that object is difficult. For them,
40 using the same context across multiple threads and protecting its
41 usage with a mutex is both higher performance and easier to
42 implement. This extension gives those applications that option by
43 relaxing the context binding requirements.
44
45 This new behavior matches the requirements of AGL, while providing
46 a feature not specified in WGL.
47
48IP Status
49
50 Open-source; freely implementable.
51
52Issues
53
54 None.
55
56New Procedures and Functions
57
58 None.
59
60New Tokens
61
62 None.
63
Eric Anholt5f889c52011-02-24 15:25:59 -080064Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
65
66 Replace the following sentence from section 2.2 Rendering Contexts:
67 In addition, a rendering context can be current for only one
68 thread at a time.
69 with:
70 In addition, an indirect rendering context can be current for
71 only one thread at a time. A direct rendering context may be
72 current to multiple threads, with synchronization of access to
73 the context thruogh the GL managed by the application through
74 mutexes.
75
Eric Anholt49d7e482011-02-03 17:26:02 -080076Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
77
Eric Anholt5f889c52011-02-24 15:25:59 -080078 Replace the following sentence from section 3.3.7 Rendering Contexts:
Eric Anholt49d7e482011-02-03 17:26:02 -080079 If ctx is current to some other thread, then
80 glXMakeContextCurrent will generate a BadAccess error.
Eric Anholt5f889c52011-02-24 15:25:59 -080081 with:
82 If ctx is an indirect context current to some other thread,
83 then glXMakeContextCurrent will generate a BadAccess error.
Eric Anholt49d7e482011-02-03 17:26:02 -080084
Eric Anholt5f889c52011-02-24 15:25:59 -080085 Replace the following sentence from section 3.5 Rendering Contexts:
Eric Anholt49d7e482011-02-03 17:26:02 -080086 If ctx is current to some other thread, then
87 glXMakeCurrent will generate a BadAccess error.
Eric Anholt5f889c52011-02-24 15:25:59 -080088 with:
89 If ctx is an indirect context current to some other thread,
90 then glXMakeCurrent will generate a BadAccess error.
Eric Anholt49d7e482011-02-03 17:26:02 -080091
92GLX Protocol
93
Eric Anholt5f889c52011-02-24 15:25:59 -080094 None. The GLX extension only extends to direct rendering contexts.
Eric Anholt49d7e482011-02-03 17:26:02 -080095
96Errors
97
98 None.
99
100New State
101
102 None.
103
104Issues
105
106 (1) What happens if the app binds a context/drawable in multiple
107 threads, then binds a different context/thread in one of them?
108
109 As with binding a new context from the current thread, the old
110 context's refcount is reduced and the new context's refcount is
111 increased.
112
113 (2) What happens if the app binds a context/drawable in multiple
114 threads, then binds None/None in one of them?
115
116 The GLX context is unreferenced from that thread, and the other
117 threads retain their GLX context binding.
118
119 (3) What happens if the app binds a context/drawable in 7 threads,
120 then destroys the context in one of them?
121
122 As with GLX context destruction previously, the XID is destroyed
123 but the context remains usable by threads that have the context
124 current.
125
126 (4) What happens if the app binds a new drawable/readable with
127 glXMakeCurrent() when it is already bound to another thread?
128
129 The context becomes bound to the new drawable/readable, and
130 further rendering in either thread will use the new
131 drawable/readable.
132
133 (5) What requirements should be placed on the user managing contexts
134 from multiple threads?
135
136 The intention is to allow multithreaded access to the GL at the
137 minimal performance cost, so requiring that the GL do general
138 synchronization (beyond that already required by context sharing)
139 is not an option, and synchronizing of GL's access to the GL
140 context between multiple threads is left to the application to do
141 across GL calls. However, it would be unfortunate for a library
142 doing multithread_makecurrent to require that other libraries
143 share in synchronization for binding of their own contexts, so the
144 refcounting of the contexts is required to be threadsafe.
145
Eric Anholt5f889c52011-02-24 15:25:59 -0800146 (6) Does this apply to indirect contexts?
147
148 This was ignored in the initial revision of the spec. Behavior
149 for indirect contexts is left as-is.
150
Eric Anholt49d7e482011-02-03 17:26:02 -0800151Revision History
152
153 20 November 2009 Eric Anholt - initial specification
154 22 November 2009 Eric Anholt - added issues from Ian Romanick.
155 3 February 2011 Eric Anholt - updated with resolution to issues 1-3
156 3 February 2011 Eric Anholt - added issue 4, 5
157 21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
158 along with glXMakeContextCurrent() for removal.