Add the EGL_MESA_configless_context extension

This extension provides a way for an application to render to multiple
surfaces with different buffer formats without having to use multiple
contexts. An EGLContext can be created without an EGLConfig by passing
EGL_NO_CONFIG_MESA. In that case there are no restrictions on the surfaces
that can be used with the context apart from that they must be using the same
EGLDisplay.

_mesa_initialze_context can now take a NULL gl_config which will mark the
context as ‘configless’. It will memset the visual to zero in that case.
Previously the i965 and i915 drivers were explicitly creating a zeroed visual
whenever 0 is passed for the EGLConfig. Mesa needs to be aware that the
context is configless because it affects the initial value to use for
glDrawBuffer. The first time the context is bound it will set the initial
value for configless contexts depending on whether the framebuffer used is
double-buffered.

Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

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 00000000000..f2fafb35a19
--- /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)