diff options
author | marha <marha@users.sourceforge.net> | 2013-06-04 09:07:26 +0200 |
---|---|---|
committer | marha <marha@users.sourceforge.net> | 2013-06-04 09:07:26 +0200 |
commit | 150771e7aabf4c864b0b970c5b8d773634793abe (patch) | |
tree | 3d544cc0d8d06dd70e843d6ca7e4b0ef421d2758 /mesalib/docs/specs/MESA_multithread_makecurrent.spec | |
parent | fbe681216618af573ce29ca03b382b39b5919a52 (diff) | |
download | vcxsrv-150771e7aabf4c864b0b970c5b8d773634793abe.tar.gz vcxsrv-150771e7aabf4c864b0b970c5b8d773634793abe.tar.bz2 vcxsrv-150771e7aabf4c864b0b970c5b8d773634793abe.zip |
xwininfo fontconfig libX11 libXau libXdmcp libXext mesa libXinerama libxcb libxcb/xcb-proto libfontenc pixman xkbcomp mkfontscale xkeyboard-config git update 4 Jun 2013
xserver commit c21344add2fc589df83b29be5831c36a372201bd
libxcb commit 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12
libxcb/xcb-proto commit bdfedfa57a13ff805580cfacafc70f9cc55df363
xkeyboard-config commit dad9ade4e83d1ef5a517fcc4cc9ad3a79b47acce
libX11 commit 8496122eb00ce6cd5d2308ee54f64b68c378e455
libXdmcp commit 0b443c1b769b9c9a3b45b4252afe07e18b709ff4
libXext commit d8366afbb0d2e4fbb1e419b1187f490522270bea
libfontenc commit 3acba630d8b57084f7e92c15732408711ed5137a
libXinerama commit 6e1d1dc328ba8162bba2f4694e7f3c706a1491ff
libXau commit 899790011304c4029e15abf410e49ce7cec17e0a
xkbcomp commit ed582f4fccd4e23abcfba8b3b03649fea6414f44
pixman commit 2acfac5f8e097ee2ae225d986f981b55d65dd152
mkfontscale commit 19e2cb7c6a3ec2c5b1bc0d24866fa685eef0ee13
xwininfo commit ba0d1b0da21d2dbdd81098ed5778f3792b472e13
fontconfig commit cd9b1033a68816a7acfbba1718ba0aa5888f6ec7
mesa commit 7bafd88c153e395274b632e7eae4bc9fc3aec1d2
Diffstat (limited to 'mesalib/docs/specs/MESA_multithread_makecurrent.spec')
-rw-r--r-- | mesalib/docs/specs/MESA_multithread_makecurrent.spec | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/mesalib/docs/specs/MESA_multithread_makecurrent.spec b/mesalib/docs/specs/MESA_multithread_makecurrent.spec new file mode 100644 index 000000000..5065c2fc0 --- /dev/null +++ b/mesalib/docs/specs/MESA_multithread_makecurrent.spec @@ -0,0 +1,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. |