forked from KolibriOS/kolibrios
159 lines
4.8 KiB
RPMSpec
159 lines
4.8 KiB
RPMSpec
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.
|