summaryrefslogtreecommitdiffstats
path: root/docs/specs
diff options
context:
space:
mode:
Diffstat (limited to 'docs/specs')
-rw-r--r--docs/specs/MESA_configless_context.spec125
1 files changed, 125 insertions, 0 deletions
diff --git a/docs/specs/MESA_configless_context.spec b/docs/specs/MESA_configless_context.spec
new file mode 100644
index 0000000..f2fafb3
--- /dev/null
+++ b/docs/specs/MESA_configless_context.spec
@@ -0,0 +1,125 @@
+Name
+
+ MESA_configless_context
+
+Name Strings
+
+ EGL_MESA_configless_context
+
+Contact
+
+ Neil Roberts <neil.s.roberts@intel.com>
+
+Status
+
+ Proposal
+
+Version
+
+ Version 1, February 28, 2014
+
+Number
+
+ EGL Extension #not assigned
+
+Dependencies
+
+ Requires EGL 1.4 or later. This extension is written against the
+ wording of the EGL 1.4 specification.
+
+Overview
+
+ This extension provides a means to use a single context to render to
+ multiple surfaces which have different EGLConfigs. Without this extension
+ the EGLConfig for every surface used by the context must be compatible
+ with the one used by the context. The only way to render to surfaces with
+ different formats would be to create multiple contexts but this is
+ inefficient with modern GPUs where this restriction is unnecessary.
+
+IP Status
+
+ Open-source; freely implementable.
+
+New Procedures and Functions
+
+ None.
+
+New Tokens
+
+ Accepted as <config> in eglCreateContext
+
+ EGL_NO_CONFIG_MESA ((EGLConfig)0)
+
+Additions to the EGL Specification section "2.2 Rendering Contexts and Drawing
+Surfaces"
+
+ Add the following to the 3rd paragraph:
+
+ "EGLContexts can also optionally be created with respect to an EGLConfig
+ depending on the parameters used at creation time. If a config is provided
+ then additional restrictions apply on what surfaces can be used with the
+ context."
+
+ Replace the last sentence of the 6th paragraph with:
+
+ "In order for a context to be compatible with a surface they both must have
+ been created with respect to the same EGLDisplay. If the context was
+ created without respect to an EGLConfig then there are no further
+ constraints. Otherwise they are only compatible if:"
+
+ Remove the last bullet point in the list of constraints.
+
+Additions to the EGL Specification section "3.7.1 Creating Rendering Contexts"
+
+ Replace the paragraph starting "If config is not a valid EGLConfig..."
+ with
+
+ "The config argument can either be a valid EGLConfig or EGL_NO_CONFIG_MESA.
+ If it is neither of these then an EGL_BAD_CONFIG error is generated. If a
+ valid config is passed then the error will also be generated if the config
+ does not support the requested client API (this includes requesting
+ creation of an OpenGL ES 1.x context when the EGL_RENDERABLE_TYPE
+ attribute of config does not contain EGL_OPENGL_ES_BIT, or creation of an
+ OpenGL ES 2.x context when the attribute does not contain
+ EGL_OPENGL_ES2_BIT).
+
+ Passing EGL_NO_CONFIG_MESA will create a configless context. When a
+ configless context is used with the OpenGL API it can be assumed that the
+ initial values of the context's state will be decided when the context is
+ first made current. In particular this means that the decision of whether
+ to use GL_BACK or GL_FRONT for the initial value of the first output in
+ glDrawBuffers will be decided based on the config of the draw surface when
+ it is first bound."
+
+Additions to the EGL Specification section "3.7.3 Binding Contexts and
+Drawables"
+
+ Replace the first bullet point with the following:
+
+ "* If draw or read are not compatible with ctx as described in section 2.2,
+ then an EGL_BAD_MATCH error is generated."
+
+ Add a second bullet point after that:
+
+ "* If draw and read are not compatible with each other as described in
+ section 2.2, then an EGL_BAD_MATCH error is generated."
+
+Issues
+
+ 1. What happens when an OpenGL context with a double-buffered surface and
+ draw buffer set to GL_BACK is made current with a single-buffered
+ surface?
+
+ NOT RESOLVED: There are a few options here. An implementation can
+ raise an error, change the drawbuffer state to GL_FRONT or just do
+ nothing, expecting the application to set GL_FRONT drawbuffer before
+ drawing. However, this extension deliberately does not specify any
+ required behavior in this corner case and applications should avoid
+ mixing single- and double-buffered surfaces with configless contexts.
+
+ Future extensions may specify required behavior in this case.
+
+Revision History
+
+ Version 1, February 28, 2014
+ Initial draft (Neil Roberts)