Subversion Repositories Kolibri OS

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
5563 serge 1 
Name
2 
 
3 
    MESA_multithread_makecurrent
4 
 
5 
Name Strings
6 
 
7 
    GLX_MESA_multithread_makecurrent
8 
 
9 
Contact
10 
 
11 
    Eric Anholt (eric@anholt.net)
12 
 
13 
Status
14 
 
15 
    Not shipping.
16 
 
17 
Version
18 
 
19 
    Last Modified Date:  21 February 2011
20 
 
21 
Number
22 
 
23 
    TBD
24 
 
25 
Dependencies
26 
 
27 
    OpenGL 1.0 or later is required.
28 
    GLX 1.3 or later is required.
29 
 
30 
Overview
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 
 
48 
IP Status
49 
 
50 
    Open-source; freely implementable.
51 
 
52 
Issues
53 
 
54 
    None.
55 
 
56 
New Procedures and Functions
57 
 
58 
    None.
59 
 
60 
New Tokens
61 
 
62 
    None.
63 
 
64 
Changes 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 
 
76 
Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
77 
 
78 
    Replace the following sentence from section 3.3.7 Rendering Contexts:
79 
	If ctx is current to some other thread, then
80 
	glXMakeContextCurrent will generate a BadAccess error.
81 
    with:
82 
	If ctx is an indirect context current to some other thread,
83 
	then glXMakeContextCurrent will generate a BadAccess error.
84 
 
85 
    Replace the following sentence from section 3.5 Rendering Contexts:
86 
	If ctx is current to some other thread, then
87 
	glXMakeCurrent will generate a BadAccess error.
88 
    with:
89 
	If ctx is an indirect context current to some other thread,
90 
	then glXMakeCurrent will generate a BadAccess error.
91 
 
92 
GLX Protocol
93 
 
94 
    None.  The GLX extension only extends to direct rendering contexts.
95 
 
96 
Errors
97 
 
98 
    None.
99 
 
100 
New State
101 
 
102 
    None.
103 
 
104 
Issues
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 
 
146 
    (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 
 
151 
Revision 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.