[PATCH 3/5] opengl32: Fix extension checks on OpenGL core profile contexts.

[Roderick Colenbrander]

On Mon, Jan 5, 2015 at 2:02 PM, Matteo Bruni <matteo.mystral at gmail.com>
wrote:

> 2015-01-05 21:17 GMT+01:00 Henri Verbeet <hverbeet at gmail.com>:
> > On 5 January 2015 at 20:19, Matteo Bruni <matteo.mystral at gmail.com>
> wrote:
> >> 2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150105/76913835/attachment.html>