On Mon, Jan 5, 2015 at 2:02 PM, Matteo Bruni matteo.mystral@gmail.com wrote:
2015-01-05 21:17 GMT+01:00 Henri Verbeet hverbeet@gmail.com:
On 5 January 2015 at 20:19, Matteo Bruni matteo.mystral@gmail.com
wrote:
2015-01-05 18:33 GMT+01:00 Henri Verbeet hverbeet@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.