2015-01-05 23:35 GMT+01:00 Matteo Bruni matteo.mystral@gmail.com:
2015-01-05 23:11 GMT+01:00 Ken Thomases ken@codeweavers.com:
On Jan 5, 2015, at 2:58 PM, cdavis5x@gmail.com wrote:
On Jan 5, 2015, at 9:17 AM, Matteo Bruni mbruni@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.
So I did that and it turns out Windows allows just about everything.
Specifically I tested creating and making use of a forward-compatible core profile context on a pixel format with accumulation buffer and one aux buffer. That works just fine for me on both AMD and Nvidia Windows boxes.
The test app sources are attached, if someone can verify that it's the same thing on Intel (on Windows) that would be great. Great also if you can point out any critical mistake in the test app.
About the patch, I'm a bit undecided. One option is to let the context creation fail when using invalid pixel formats, similarly to the current version. I found this in the WGL_create_context spec:
--- On failure wglCreateContextAttribsARB returns NULL. Extended error information can be obtained with GetLastError. Conditions that cause failure include:
...
* If the pixel format associated with <hDC> does not support OpenGL contexts providing the requested API major and minor version, forward-compatible flag, and/or debug context flag, then ERROR_INVALID_PIXEL_FORMAT is generated. ---
The other possibility is to ignore aux and accumulation buffers settings in the same vein as the pbuffer bit. That means the application is not actually getting the pixel format it expects, but since only forward-compatible core contexts are supported anyway I don't think that is going to matter in practice. Either way it probably doesn't matter much in the end, until we find some actual OpenGL application which expects success instead of failure (or the other way around).