forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
158 lines
4.8 KiB
158 lines
4.8 KiB
Name |
|
|
|
MESA_multithread_makecurrent |
|
|
|
Name Strings |
|
|
|
GLX_MESA_multithread_makecurrent |
|
|
|
Contact |
|
|
|
Eric Anholt ([email protected]) |
|
|
|
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.
|
|
|