On 15 September 2015 at 14:27, Boyan Ding <[email protected]> wrote: > 2015-09-15 1:35 GMT+08:00 Emil Velikov <[email protected]>: >> From: Matthew Waters <[email protected]> >> >> As of version 15 of the EGL_KHR_create_context spec, debug contexts >> are allowed for ES contexts. We should allow creation instead of >> erroring. >> >> While we're here provide a more comprehensive checking for the other two >> flags - ROBUST_ACCESS_BIT_KHR and FORWARD_COMPATIBLE_BIT_KHR >> >> v2 [Emil Velikov] Rebase. Minor tweak in commit message. >> >> Cc: Boyan Ding <[email protected]> >> Cc: Chad Versace <[email protected]> >> Cc: "10.6 11.0" <[email protected]> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91044 >> Signed-off-by: Matthew Waters <[email protected]> >> Signed-off-by: Emil Velikov <[email protected]> >> --- >> src/egl/main/eglcontext.c | 49 >> ++++++++++++++++++++++++++++++++++++++++++----- >> 1 file changed, 44 insertions(+), 5 deletions(-) >> >> diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c >> index 588f489..ae19862 100644 >> --- a/src/egl/main/eglcontext.c >> +++ b/src/egl/main/eglcontext.c >> @@ -152,12 +152,51 @@ _eglParseContextAttribList(_EGLContext *ctx, >> _EGLDisplay *dpy, >> >> /* The EGL_KHR_create_context spec says: >> * >> - * "Flags are only defined for OpenGL context creation, and >> - * specifying a flags value other than zero for other types of >> - * contexts, including OpenGL ES contexts, will generate an >> - * error." >> + * "If the EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR flag bit is set in >> + * EGL_CONTEXT_FLAGS_KHR, then a <debug context> will be >> created. >> + * [...] >> + * In some cases a debug context may be identical to a >> non-debug >> + * context. This bit is supported for OpenGL and OpenGL ES >> + * contexts." >> + */ >> + if ((val & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR) && >> + (api != EGL_OPENGL_API && api != EGL_OPENGL_ES_API)) { >> + err = EGL_BAD_ATTRIBUTE; >> + break; >> + } >> + >> + /* The EGL_KHR_create_context spec says: >> + * >> + * "If the EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR flag >> bit >> + * is set in EGL_CONTEXT_FLAGS_KHR, then a <forward-compatible> >> + * context will be created. Forward-compatible contexts are >> + * defined only for OpenGL versions 3.0 and later. They must >> not >> + * support functionality marked as <deprecated> by that >> version of >> + * the API, while a non-forward-compatible context must support >> + * all functionality in that version, deprecated or not. This >> bit >> + * is supported for OpenGL contexts, and requesting a >> + * forward-compatible context for OpenGL versions less than 3.0 >> + * will generate an error." >> + */ >> + if ((val & EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR) && >> + (api != EGL_OPENGL_API || ctx->ClientMajorVersion < 3)) { >> + err = EGL_BAD_ATTRIBUTE; >> + break; >> + } >> + >> + /* The EGL_KHR_create_context_spec says: >> + * >> + * "If the EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR bit is set >> in >> + * EGL_CONTEXT_FLAGS_KHR, then a context supporting <robust >> buffer >> + * access> will be created. Robust buffer access is defined in >> the >> + * GL_ARB_robustness extension specification, and the resulting >> + * context must also support either the GL_ARB_robustness >> + * extension, or a version of OpenGL incorporating equivalent >> + * functionality. This bit is supported for OpenGL contexts. >> */ >> - if (api != EGL_OPENGL_API && val != 0) { >> + if ((val & EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR) && >> + (api != EGL_OPENGL_API || >> + !dpy->Extensions.EXT_create_context_robustness)) { >> err = EGL_BAD_ATTRIBUTE; >> break; >> } > > I wonder if it's necessary to check the validity of the flags here, > since driCreateContextAttribs in src/mesa/drivers/dri/common/dri_util.c > also check those flags and the logic there seems to work. > Imho they are two are different things.
The glx/egl/etc ones are used to determine if the winsys layer supports/sets them while, the DRI ones are used for internal representation. As we don't know if tomorrow's new flags will require changes within the loader(s), dri module(s) and/or both, it's nice to have things separated. Although I do see how they feel unnecessary atm. If people feel against them we can nuke them. -Emil _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
