January 2015 - Wine-Devel - list.winehq.org

Re: windowscodecs: DibDecoder_CreateInstance() is unused so remove it.

by Matteo Bruni

2015-01-05 20:10 GMT+01:00 Vincent Povirk <madewokherd(a)gmail.com>: > The original intent was that this could be used by d3dx9 to implement > reading of the DIB format, but I didn't have the knowledge of d3dx9 to > test that this really does what is needed. I'm not really familiar with that part of d3dx9 but I see a convert_dib_to_bmp function in surface.c which suggests that a WIC DIB decoder is probably unnecessary for d3dx9.

Jan. 6, 2015

Re: [PATCH] xaudio2_7: add stub DLL

by Alexandre Julliard

Mark Harmstone <hellas(a)burntcomma.com> writes: > diff --git a/dlls/xaudio2_7/xaudio2_7.spec b/dlls/xaudio2_7/xaudio2_7.spec > new file mode 100644 > index 0000000..e69de29 Please list stubs for all the exported functions. -- Alexandre Julliard julliard(a)winehq.org

Jan. 6, 2015

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

by Roderick Colenbrander

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.

Jan. 6, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Matteo Bruni

2015-01-05 23:11 GMT+01:00 Ken Thomases <ken(a)codeweavers.com>: > On Jan 5, 2015, at 2:58 PM, cdavis5x(a)gmail.com wrote: > >> >>> On Jan 5, 2015, at 9:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> >>> + attribs[n++] = kCGLPFAAuxBuffers; >>> + attribs[n++] = pf->aux_buffers; >> You must reject any pixel format with >0 auxiliary buffers when creating a core profile context. CGL will specifically fail the ChoosePixelFormat (with error 10000, kCGLBadAttribute) if you specify both a GL version >= 3.2 and a non-zero number of auxiliary buffers. > > Yes, CGL will fail. However, I don't think it's correct that the pixel format should be rejected (by which, I take it, you mean that context creation should fail). I believe that the auxiliary buffers component of the pixel format should just be ignored. > > According to the spec, the failure should happen at wglMakeCurrent() time. See issue 3 at <https://www.opengl.org/registry/specs/ARB/wgl_create_context.txt>. > > Annoyingly, that may require adding explicit tests to the make-current code path to check the pixel format of the target drawable. Annoying indeed. I'm going to write a test for this. >>> + if (pf->accum_mode) >>> + { >>> + attribs[n++] = kCGLPFAAccumSize; >>> + attribs[n++] = color_modes[pf->accum_mode - 1].color_bits; >>> + } >> You must also reject any pixel format with an accumulation buffer when creating a core profile context, for the same reason. > > See above. > >>> + if (core) >>> + { >>> + attribs[n++] = kCGLPFAOpenGLProfile; >>> + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; >>> + } >> There’s a constant for requesting a 4.x core context, too. (But it’s only defined in the 10.9 and 10.10 SDKs.) You might consider using it if the requested version is >= 4.0. That way, creation will fail if the system doesn’t support it. > > That's something Matteo and I discussed a bit. I think it's OK to add support for just 3.2 core at first. (Of course, I have no objection to adding support for 4.1 core now, either. Although I have seen a recent report on Apple's dev forums that simply requesting a 4.x profile introduced performance problems in an otherwise-unchanged program. <https://devforums.apple.com/message/1089523#1089523>) > > However, that raises another issue. The logic in macdrv_wglCreateContextAttribsARB() in this patch does: > > if (major > 3 || (major == 3 && minor >= 2)) > { > … accept forward-compatible core profile … > } > > That should be stricter. It should accept exactly 3.2 (and, per the comment below, 3.1). It should reject greater than that. If the client app requests, hypothetically, 5.0, we need to reject it because we can't satisfy such a request. In principle you're correct, but it happens to be that GL 3.3, 4.0 and 4.1 are forward compatible with GL 3.2 (there are no new deprecations or removed functionalities) so if we get a 4.1 context we're fine. I should probably add an explicit check for version <= 4.1 (4.2 adds new deprecations for NUM_COMPRESSED_TEXTURE_FORMATS and COMPRESSED_TEXTURE_FORMATS). Obviously this also means I have to check the version of the returned context and fail if it's less than the requested version. > If/when support is added for kCGLOGLPVersion_GL4_Core and the current system actually supports it, it should accept 3.1, 3.2, 3.3, 4.0, and 4.1 forward-compatible contexts. > > >>> + if (major > 3 || (major == 3 && minor >= 2)) >>> + { >>> + if (!(flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB)) >>> + { >>> + WARN("OS X only supports forward-compatible 3.2+ contexts\n"); >>> + SetLastError(ERROR_INVALID_VERSION_ARB); >>> + return NULL; >>> + } >> Just so you know, a side effect of this is that our GL 3.x tests get skipped here, because they don’t specify the FOWARD_COMPATIBLE bit. > > Good point. > >> >> Also, you should consider rejecting the DEBUG flag, if it’s set: OS X never returns that flag. (Or do you want to hook glGetInteger(3G) to return the debug flag if it’s set?) > > Seems like a good suggestion. On the other hand, the spec says "In some cases a debug context may be identical to a non-debug context." So, it's acceptable to treat the DEBUG flag as a no-op. > > >>> + else if (major == 3) >>> + { >>> + WARN("OS X doesn't support 3.0 or 3.1 contexts\n"); >>> + SetLastError(ERROR_INVALID_VERSION_ARB); >>> + return NULL; >>> + } >> I think we can support requests for 3.1 contexts, if the FORWARD_COMPATIBLE bit is set; we just won’t advertise GL_ARB_compatibility. > > I think you're right. At some previous time, I had convinced myself that that wasn't allowed, but on reviewing the OpenGL 3.1 and 3.2 specs, it seems that it is. > > -Ken I maintain my previous comments are valid where I didn't specifically reply here :P

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Ken Thomases

On Jan 5, 2015, at 2:04 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jan 5, 2015, at 10:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > >> + register_extension("WGL_ARB_create_context"); >> + register_extension("WGL_ARB_create_context_profile"); >> + opengl_funcs.ext.p_wglCreateContextAttribsARB = macdrv_wglCreateContextAttribsARB; > > These should only be advertised when building against the 10.7 SDK or later. So, this should be guarded by the SDK #if directive. > > Also, given that it's possible to build against a 10.7+ SDK but target deployment back to 10.6, I'm tempted to say we should determine if core profiles are actually available and only advertise those extensions if so. Basically, call CGLChoosePixelFormat() with the simplest set of attributes that specify the core profile and see if it succeeds. Actually, after reviewing the WGL_ARB_create_context spec, I have changed my mind about this. Those extensions and the entry point can still be advertised regardless of the SDK or the actual capabilities of the system. However, wglCreateContextAttribsARB() should reject requests for anything which can't be supported because of the SDK or the capabilities of the system. Probably the capabilities of the system with respect to core profile support should be tested once during initialization and recorded. -Ken

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Ken Thomases

On Jan 5, 2015, at 4:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2015-01-05 21:58 GMT+01:00 <cdavis5x(a)gmail.com>: >> >> I think we can support requests for 3.1 contexts, if the FORWARD_COMPATIBLE bit is set; we just won’t advertise GL_ARB_compatibility. > > Unfortunately not, because 3.2 deprecates MAX_VARYING_COMPONENTS and > MAX_VARYING_FLOATS. Ah, you're right. Ignore what I said about this in my reply to Chip's email. -Ken

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Ken Thomases

On Jan 5, 2015, at 2:58 PM, cdavis5x(a)gmail.com wrote: > >> On Jan 5, 2015, at 9:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > >> + attribs[n++] = kCGLPFAAuxBuffers; >> + attribs[n++] = pf->aux_buffers; > You must reject any pixel format with >0 auxiliary buffers when creating a core profile context. CGL will specifically fail the ChoosePixelFormat (with error 10000, kCGLBadAttribute) if you specify both a GL version >= 3.2 and a non-zero number of auxiliary buffers. Yes, CGL will fail. However, I don't think it's correct that the pixel format should be rejected (by which, I take it, you mean that context creation should fail). I believe that the auxiliary buffers component of the pixel format should just be ignored. According to the spec, the failure should happen at wglMakeCurrent() time. See issue 3 at <https://www.opengl.org/registry/specs/ARB/wgl_create_context.txt>. Annoyingly, that may require adding explicit tests to the make-current code path to check the pixel format of the target drawable. >> + if (pf->accum_mode) >> + { >> + attribs[n++] = kCGLPFAAccumSize; >> + attribs[n++] = color_modes[pf->accum_mode - 1].color_bits; >> + } > You must also reject any pixel format with an accumulation buffer when creating a core profile context, for the same reason. See above. >> + if (core) >> + { >> + attribs[n++] = kCGLPFAOpenGLProfile; >> + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; >> + } > There’s a constant for requesting a 4.x core context, too. (But it’s only defined in the 10.9 and 10.10 SDKs.) You might consider using it if the requested version is >= 4.0. That way, creation will fail if the system doesn’t support it. That's something Matteo and I discussed a bit. I think it's OK to add support for just 3.2 core at first. (Of course, I have no objection to adding support for 4.1 core now, either. Although I have seen a recent report on Apple's dev forums that simply requesting a 4.x profile introduced performance problems in an otherwise-unchanged program. <https://devforums.apple.com/message/1089523#1089523>) However, that raises another issue. The logic in macdrv_wglCreateContextAttribsARB() in this patch does: if (major > 3 || (major == 3 && minor >= 2)) { … accept forward-compatible core profile … } That should be stricter. It should accept exactly 3.2 (and, per the comment below, 3.1). It should reject greater than that. If the client app requests, hypothetically, 5.0, we need to reject it because we can't satisfy such a request. If/when support is added for kCGLOGLPVersion_GL4_Core and the current system actually supports it, it should accept 3.1, 3.2, 3.3, 4.0, and 4.1 forward-compatible contexts. >> + if (major > 3 || (major == 3 && minor >= 2)) >> + { >> + if (!(flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB)) >> + { >> + WARN("OS X only supports forward-compatible 3.2+ contexts\n"); >> + SetLastError(ERROR_INVALID_VERSION_ARB); >> + return NULL; >> + } > Just so you know, a side effect of this is that our GL 3.x tests get skipped here, because they don’t specify the FOWARD_COMPATIBLE bit. Good point. > > Also, you should consider rejecting the DEBUG flag, if it’s set: OS X never returns that flag. (Or do you want to hook glGetInteger(3G) to return the debug flag if it’s set?) Seems like a good suggestion. On the other hand, the spec says "In some cases a debug context may be identical to a non-debug context." So, it's acceptable to treat the DEBUG flag as a no-op. >> + else if (major == 3) >> + { >> + WARN("OS X doesn't support 3.0 or 3.1 contexts\n"); >> + SetLastError(ERROR_INVALID_VERSION_ARB); >> + return NULL; >> + } > I think we can support requests for 3.1 contexts, if the FORWARD_COMPATIBLE bit is set; we just won’t advertise GL_ARB_compatibility. I think you're right. At some previous time, I had convinced myself that that wasn't allowed, but on reviewing the OpenGL 3.1 and 3.2 specs, it seems that it is. -Ken

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Matteo Bruni

2015-01-05 21:58 GMT+01:00 <cdavis5x(a)gmail.com>: > >> On Jan 5, 2015, at 9:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> >> As an aside, reported WGL extensions don't depend on the specific >> GL context (e.g. WGL_ARB_pbuffer is reported as supported even on core >> profile contexts). > Do real Windows drivers behave like this? Yep, both AMD and Nvidia. >> @@ -1272,6 +1273,175 @@ static BOOL init_gl_info(void) > […] >> +/********************************************************************** >> + * create_context >> + */ >> +static BOOL create_context(struct wgl_context *context, CGLContextObj share, BOOL core) >> +{ > […] >> + attribs[n++] = kCGLPFAAuxBuffers; >> + attribs[n++] = pf->aux_buffers; > You must reject any pixel format with >0 auxiliary buffers when creating a core profile context. CGL will specifically fail the ChoosePixelFormat (with error 10000, kCGLBadAttribute) if you specify both a GL version >= 3.2 and a non-zero number of auxiliary buffers. Well, that's responsibility of the application. If the application tries to create a core context on a pixel format with aux buffers the context creation will indeed fail as expected. >> + >> + attribs[n++] = kCGLPFAColorSize; >> + attribs[n++] = color_modes[pf->color_mode].color_bits; >> + attribs[n++] = kCGLPFAAlphaSize; >> + attribs[n++] = color_modes[pf->color_mode].alpha_bits; >> + if (color_modes[pf->color_mode].is_float) >> + attribs[n++] = kCGLPFAColorFloat; >> + >> + attribs[n++] = kCGLPFADepthSize; >> + attribs[n++] = pf->depth_bits; >> + >> + attribs[n++] = kCGLPFAStencilSize; >> + attribs[n++] = pf->stencil_bits; >> + >> + if (pf->stereo) >> + attribs[n++] = kCGLPFAStereo; >> + >> + if (pf->accum_mode) >> + { >> + attribs[n++] = kCGLPFAAccumSize; >> + attribs[n++] = color_modes[pf->accum_mode - 1].color_bits; >> + } > You must also reject any pixel format with an accumulation buffer when creating a core profile context, for the same reason. Same as above. For pbuffers things are different because Windows has no problems creating core contexts on pixel formats supporting rendering to pbuffers. Actually, on my Windows boxes pretty much all the pixel formats do support pbuffer rendering. >> + >> + /* Explicitly requesting pbuffers in CGLChoosePixelFormat fails with core contexts. */ >> + if (pf->pbuffer && !core) >> + attribs[n++] = kCGLPFAPBuffer; >> + >> + if (pf->sample_buffers && pf->samples) >> + { >> + attribs[n++] = kCGLPFASampleBuffers; >> + attribs[n++] = pf->sample_buffers; >> + attribs[n++] = kCGLPFASamples; >> + attribs[n++] = pf->samples; >> + } >> + >> + if (pf->backing_store) >> + attribs[n++] = kCGLPFABackingStore; >> + >> + if (core) >> + { >> + attribs[n++] = kCGLPFAOpenGLProfile; >> + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; >> + } > There’s a constant for requesting a 4.x core context, too. (But it’s only defined in the 10.9 and 10.10 SDKs.) You might consider using it if the requested version is >= 4.0. That way, creation will fail if the system doesn’t support it. I ignored that constant for the time being but yes, I guess it would make sense to make use of that. FWIW on my OS X box I get a 4.1 context back anyway. >> + >> + attribs[n] = 0; >> + >> + err = CGLChoosePixelFormat(attribs, &pix, &virtualScreens); >> + if (err != kCGLNoError || !pix) >> + { >> + WARN("CGLChoosePixelFormat() failed with error %d %s\n", err, CGLErrorString(err)); >> + SetLastError(ERROR_INVALID_OPERATION); > This is somewhat nitpicking, but one thing you might consider is setting the last error based on what CGL returned. For example, if you get the error kCGLBadAlloc, you could set the last error to ERROR_NO_SYSTEM_RESOURCES. True, I took the easy way out by not mapping CGL errors to Win32 ones. To tell the truth, I don't feel all that much inclined to add a facility to map those errors just for this one function... >> + return FALSE; >> + } >> + >> + err = CGLCreateContext(pix, share, &context->cglcontext); >> + CGLReleasePixelFormat(pix); >> + if (err != kCGLNoError || !context->cglcontext) >> + { >> + context->cglcontext = NULL; >> + WARN("CGLCreateContext() failed with error %d %s\n", err, CGLErrorString(err)); >> + SetLastError(ERROR_INVALID_OPERATION); > Ditto. >> @@ -2076,6 +2246,133 @@ cant_match: > […] >> +/*********************************************************************** >> + * macdrv_wglCreateContextAttribsARB >> + * >> + * WGL_ARB_create_context: wglCreateContextAttribsARB >> + */ >> +static struct wgl_context *macdrv_wglCreateContextAttribsARB(HDC hdc, >> + struct wgl_context *share_context, >> + const int *attrib_list) >> +{ > […] >> + if (major > 3 || (major == 3 && minor >= 2)) >> + { >> + if (!(flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB)) >> + { >> + WARN("OS X only supports forward-compatible 3.2+ contexts\n"); >> + SetLastError(ERROR_INVALID_VERSION_ARB); >> + return NULL; >> + } > Just so you know, a side effect of this is that our GL 3.x tests get skipped here, because they don’t specify the FOWARD_COMPATIBLE bit. Good to know, although core GL on OS X is really better exposed as a forward-compatible context. > Also, you should consider rejecting the DEBUG flag, if it’s set: OS X never returns that flag. (Or do you want to hook glGetInteger(3G) to return the debug flag if it’s set?) AFAIK as long as the context doesn't support GL 4.3 or ARB_debug_output the DEBUG flag doesn't have to have any effect. The general idea here was to ignore the issue until Apple implements this kind of functionality in its GL. >> + if (profile != WGL_CONTEXT_CORE_PROFILE_BIT_ARB) >> + { >> + WARN("Compatibility profiles for GL version >= 3.2 not supported\n"); >> + SetLastError(ERROR_INVALID_PROFILE_ARB); >> + return NULL; >> + } >> + core = TRUE; >> + } >> + else if (major == 3) >> + { >> + WARN("OS X doesn't support 3.0 or 3.1 contexts\n"); >> + SetLastError(ERROR_INVALID_VERSION_ARB); >> + return NULL; >> + } > I think we can support requests for 3.1 contexts, if the FORWARD_COMPATIBLE bit is set; we just won’t advertise GL_ARB_compatibility. Unfortunately not, because 3.2 deprecates MAX_VARYING_COMPONENTS and MAX_VARYING_FLOATS. > Chip > > >

Jan. 5, 2015

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

by Matteo Bruni

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...

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by cdavis5x＠gmail.com

> On Jan 5, 2015, at 9:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > > As an aside, reported WGL extensions don't depend on the specific > GL context (e.g. WGL_ARB_pbuffer is reported as supported even on core > profile contexts). Do real Windows drivers behave like this? > @@ -1272,6 +1273,175 @@ static BOOL init_gl_info(void) […] > +/********************************************************************** > + * create_context > + */ > +static BOOL create_context(struct wgl_context *context, CGLContextObj share, BOOL core) > +{ […] > + attribs[n++] = kCGLPFAAuxBuffers; > + attribs[n++] = pf->aux_buffers; You must reject any pixel format with >0 auxiliary buffers when creating a core profile context. CGL will specifically fail the ChoosePixelFormat (with error 10000, kCGLBadAttribute) if you specify both a GL version >= 3.2 and a non-zero number of auxiliary buffers. > + > + attribs[n++] = kCGLPFAColorSize; > + attribs[n++] = color_modes[pf->color_mode].color_bits; > + attribs[n++] = kCGLPFAAlphaSize; > + attribs[n++] = color_modes[pf->color_mode].alpha_bits; > + if (color_modes[pf->color_mode].is_float) > + attribs[n++] = kCGLPFAColorFloat; > + > + attribs[n++] = kCGLPFADepthSize; > + attribs[n++] = pf->depth_bits; > + > + attribs[n++] = kCGLPFAStencilSize; > + attribs[n++] = pf->stencil_bits; > + > + if (pf->stereo) > + attribs[n++] = kCGLPFAStereo; > + > + if (pf->accum_mode) > + { > + attribs[n++] = kCGLPFAAccumSize; > + attribs[n++] = color_modes[pf->accum_mode - 1].color_bits; > + } You must also reject any pixel format with an accumulation buffer when creating a core profile context, for the same reason. > + > + /* Explicitly requesting pbuffers in CGLChoosePixelFormat fails with core contexts. */ > + if (pf->pbuffer && !core) > + attribs[n++] = kCGLPFAPBuffer; > + > + if (pf->sample_buffers && pf->samples) > + { > + attribs[n++] = kCGLPFASampleBuffers; > + attribs[n++] = pf->sample_buffers; > + attribs[n++] = kCGLPFASamples; > + attribs[n++] = pf->samples; > + } > + > + if (pf->backing_store) > + attribs[n++] = kCGLPFABackingStore; > + > + if (core) > + { > + attribs[n++] = kCGLPFAOpenGLProfile; > + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; > + } There’s a constant for requesting a 4.x core context, too. (But it’s only defined in the 10.9 and 10.10 SDKs.) You might consider using it if the requested version is >= 4.0. That way, creation will fail if the system doesn’t support it. > + > + attribs[n] = 0; > + > + err = CGLChoosePixelFormat(attribs, &pix, &virtualScreens); > + if (err != kCGLNoError || !pix) > + { > + WARN("CGLChoosePixelFormat() failed with error %d %s\n", err, CGLErrorString(err)); > + SetLastError(ERROR_INVALID_OPERATION); This is somewhat nitpicking, but one thing you might consider is setting the last error based on what CGL returned. For example, if you get the error kCGLBadAlloc, you could set the last error to ERROR_NO_SYSTEM_RESOURCES. > + return FALSE; > + } > + > + err = CGLCreateContext(pix, share, &context->cglcontext); > + CGLReleasePixelFormat(pix); > + if (err != kCGLNoError || !context->cglcontext) > + { > + context->cglcontext = NULL; > + WARN("CGLCreateContext() failed with error %d %s\n", err, CGLErrorString(err)); > + SetLastError(ERROR_INVALID_OPERATION); Ditto. > @@ -2076,6 +2246,133 @@ cant_match: […] > +/*********************************************************************** > + * macdrv_wglCreateContextAttribsARB > + * > + * WGL_ARB_create_context: wglCreateContextAttribsARB > + */ > +static struct wgl_context *macdrv_wglCreateContextAttribsARB(HDC hdc, > + struct wgl_context *share_context, > + const int *attrib_list) > +{ […] > + if (major > 3 || (major == 3 && minor >= 2)) > + { > + if (!(flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB)) > + { > + WARN("OS X only supports forward-compatible 3.2+ contexts\n"); > + SetLastError(ERROR_INVALID_VERSION_ARB); > + return NULL; > + } Just so you know, a side effect of this is that our GL 3.x tests get skipped here, because they don’t specify the FOWARD_COMPATIBLE bit. Also, you should consider rejecting the DEBUG flag, if it’s set: OS X never returns that flag. (Or do you want to hook glGetInteger(3G) to return the debug flag if it’s set?) > + if (profile != WGL_CONTEXT_CORE_PROFILE_BIT_ARB) > + { > + WARN("Compatibility profiles for GL version >= 3.2 not supported\n"); > + SetLastError(ERROR_INVALID_PROFILE_ARB); > + return NULL; > + } > + core = TRUE; > + } > + else if (major == 3) > + { > + WARN("OS X doesn't support 3.0 or 3.1 contexts\n"); > + SetLastError(ERROR_INVALID_VERSION_ARB); > + return NULL; > + } I think we can support requests for 3.1 contexts, if the FORWARD_COMPATIBLE bit is set; we just won’t advertise GL_ARB_compatibility. Chip

Jan. 5, 2015