diff options
Diffstat (limited to 'mesalib/docs/MESA_multithread_makecurrent.spec')
| -rw-r--r-- | mesalib/docs/MESA_multithread_makecurrent.spec | 158 |
1 files changed, 0 insertions, 158 deletions
diff --git a/mesalib/docs/MESA_multithread_makecurrent.spec b/mesalib/docs/MESA_multithread_makecurrent.spec deleted file mode 100644 index 5065c2fc0..000000000 --- a/mesalib/docs/MESA_multithread_makecurrent.spec +++ /dev/null @@ -1,158 +0,0 @@ -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. |