<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 5, 2015 at 2:02 PM, Matteo Bruni <span dir="ltr"><<a href="mailto:matteo.mystral@gmail.com" target="_blank">matteo.mystral@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2015-01-05 21:17 GMT+01:00 Henri Verbeet <<a href="mailto:hverbeet@gmail.com">hverbeet@gmail.com</a>>:<br>
> On 5 January 2015 at 20:19, Matteo Bruni <<a href="mailto:matteo.mystral@gmail.com">matteo.mystral@gmail.com</a>> wrote:<br>
>> 2015-01-05 18:33 GMT+01:00 Henri Verbeet <<a href="mailto:hverbeet@gmail.com">hverbeet@gmail.com</a>>:<br>
>>> If I'm reading this correctly, this effectively ignores<br>
>>> DisabledExtensions for anything newer than GL 3.0. (And at least as<br>
>>> far as wglGetProcAddress() is concerned it affects both compatibility<br>
>>> and core contexts.)<br>
>><br>
>> Hmm, it should still work via filter_extensions().<br>
> wglGetProcAddress() calls is_extension_supported(), which calls<br>
> has_extension(NULL, ...) if major >= 3, so it doesn't go through<br>
> filter_extensions().<br>
><br>
> Most applications probably won't care, but in principle applications<br>
> can use wglGetProcAddress() to check if a function is supported. (As<br>
> opposed to glXGetProcAddress() that's allowed to return non-NULL for<br>
> unsupported functions.)<br>
<br>
</span>Oh, you're right, I missed that. So I really need the glGetStringi() wrapper.<br>
<span class=""><br>
>>> As an aside, note that winex11.drv also uses<br>
>>> "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().<br>
>><br>
>> That should be fine, that's always a compatibility context created<br>
>> with glXCreateContext().<br>
> Right, although in a way that's worse; extensions supported in<br>
> compatibility contexts aren't necessarily also supported in core<br>
> contexts. The only reason it will probably work in practice is because<br>
> of the details of the extensions being checked against that list.<br>
<br>
</span>Okay I see, I mentioned in patch 2/5 that the WGL extensions reported<br>
by wglGetExtensionsString[ARB|EXT] on Windows don't seem to depend on<br>
the GL profile in use but I guess that might just be a coincidence<br>
i.e. it just happens that the same extensions are supported in both<br>
cases.<br></blockquote><div><br></div><div>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). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So theoretically winex11.drv should generate / store the extensions<br>
list for each context. I think I'm going to ignore that part for the<br>
time being...<br></blockquote><div><br></div><div>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. <br></div><div><br> </div></div><br></div></div>