Re: [PATCH 3/5] opengl32: Fix extension checks on OpenGL core profile contexts.
On 5 January 2015 at 17:17, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
static BOOL has_extension( const char *list, const char *ext, size_t len ) { + if (!list) + { + const struct opengl_funcs *funcs = NtCurrentTeb()->glTable; + const char *gl_ext; + unsigned int i; + GLint extensions_count; + + glGetIntegerv(GL_NUM_EXTENSIONS, &extensions_count); + for (i = 0; i < extensions_count; ++i) + { + gl_ext = (const char *)funcs->ext.p_glGetStringi(GL_EXTENSIONS, i); + if (!strncmp(gl_ext, ext, len) && !gl_ext[len]) + return TRUE; + } + return FALSE; + } + If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
+ gl_version = (const char *)glGetString(GL_VERSION); + sscanf(gl_version, "%u", &major); + if (major >= 3) + { It seems tempting to just flag the context in wglCreateContextAttribsARB() under the appropriate conditions, perhaps in a similar way to wgl_handle_type. Not sure if it would really make it better though.
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
On 5 January 2015 at 17:17, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
static BOOL has_extension( const char *list, const char *ext, size_t len ) { + if (!list) + { + const struct opengl_funcs *funcs = NtCurrentTeb()->glTable; + const char *gl_ext; + unsigned int i; + GLint extensions_count; + + glGetIntegerv(GL_NUM_EXTENSIONS, &extensions_count); + for (i = 0; i < extensions_count; ++i) + { + gl_ext = (const char *)funcs->ext.p_glGetStringi(GL_EXTENSIONS, i); + if (!strncmp(gl_ext, ext, len) && !gl_ext[len]) + return TRUE; + } + return FALSE; + } + If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
Hmm, it should still work via filter_extensions(). On the other hand we don't filter the extensions the application queries through glGetStringi(GL_EXTENSIONS, i), so yeah, that is missing and I should add that (maybe in a separate patch?)
+ gl_version = (const char *)glGetString(GL_VERSION); + sscanf(gl_version, "%u", &major); + if (major >= 3) + { It seems tempting to just flag the context in wglCreateContextAttribsARB() under the appropriate conditions, perhaps in a similar way to wgl_handle_type. Not sure if it would really make it better though.
I'm going to give it a try and see how it looks.
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
That should be fine, that's always a compatibility context created with glXCreateContext().
On 5 January 2015 at 20:19, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
Hmm, it should still work via filter_extensions(). wglGetProcAddress() calls is_extension_supported(), which calls has_extension(NULL, ...) if major >= 3, so it doesn't go through filter_extensions().
Most applications probably won't care, but in principle applications can use wglGetProcAddress() to check if a function is supported. (As opposed to glXGetProcAddress() that's allowed to return non-NULL for unsupported functions.)
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
That should be fine, that's always a compatibility context created with glXCreateContext(). Right, although in a way that's worse; extensions supported in compatibility contexts aren't necessarily also supported in core contexts. The only reason it will probably work in practice is because of the details of the extensions being checked against that list.
2015-01-05 21:17 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
On 5 January 2015 at 20:19, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
Hmm, it should still work via filter_extensions(). wglGetProcAddress() calls is_extension_supported(), which calls has_extension(NULL, ...) if major >= 3, so it doesn't go through filter_extensions().
Most applications probably won't care, but in principle applications can use wglGetProcAddress() to check if a function is supported. (As opposed to glXGetProcAddress() that's allowed to return non-NULL for unsupported functions.)
Oh, you're right, I missed that. So I really need the glGetStringi() wrapper.
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
That should be fine, that's always a compatibility context created with glXCreateContext(). Right, although in a way that's worse; extensions supported in compatibility contexts aren't necessarily also supported in core contexts. The only reason it will probably work in practice is because of the details of the extensions being checked against that list.
Okay I see, I mentioned in patch 2/5 that the WGL extensions reported by wglGetExtensionsString[ARB|EXT] on Windows don't seem to depend on the GL profile in use but I guess that might just be a coincidence i.e. it just happens that the same extensions are supported in both cases. So theoretically winex11.drv should generate / store the extensions list for each context. I think I'm going to ignore that part for the time being...
On Mon, Jan 5, 2015 at 2:02 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
2015-01-05 21:17 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
On 5 January 2015 at 20:19, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>:
If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
Hmm, it should still work via filter_extensions(). wglGetProcAddress() calls is_extension_supported(), which calls has_extension(NULL, ...) if major >= 3, so it doesn't go through filter_extensions().
Most applications probably won't care, but in principle applications can use wglGetProcAddress() to check if a function is supported. (As opposed to glXGetProcAddress() that's allowed to return non-NULL for unsupported functions.)
Oh, you're right, I missed that. So I really need the glGetStringi() wrapper.
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
That should be fine, that's always a compatibility context created with glXCreateContext(). Right, although in a way that's worse; extensions supported in compatibility contexts aren't necessarily also supported in core contexts. The only reason it will probably work in practice is because of the details of the extensions being checked against that list.
Okay I see, I mentioned in patch 2/5 that the WGL extensions reported by wglGetExtensionsString[ARB|EXT] on Windows don't seem to depend on the GL profile in use but I guess that might just be a coincidence i.e. it just happens that the same extensions are supported in both cases.
It probably won't matter, but did you try to call wglGetProcAddress on the Core context to fetch the entry-point again? Technically the function pointers are only valued for the current context. In theory you could get a different implementation for the Core context, though I doubt it. I would assume it is a coincidence for now. Maybe behavior is different on other GL implementations, which support mostly Core features like PowerVR based Intel Win8 tablet (e.g. some Dell Venue 8 or other models).
So theoretically winex11.drv should generate / store the extensions list for each context. I think I'm going to ignore that part for the time being...
Sounds reasonable. Maybe we have to deal with it if we wanted to support setups with multiple GPUs with different capabilities / from different vendors. Probably only realistic on Mesa based drivers, but such an edge case right now.
participants (3)
-
Henri Verbeet -
Matteo Bruni -
Roderick Colenbrander