docs: move specs to a separate folder

Handle legacy/obsolete specs as well
List all specs in extensions.html
Mark 'OLD' extensions as obsolete in extensions.html
Update the spec location in old relnotes

Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Brian Paul <[email protected]>

1 files changed, 0 insertions, 158 deletions

diff --git a/docs/MESA_multithread_makecurrent.spec b/docs/MESA_multithread_makecurrent.spec
deleted file mode 100644
index 5065c2fc0a3..00000000000
--- a/docs/MESA_multithread_makecurrent.spec
+++ /dev/null
@@ -1,158 +0,0 @@
-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.