Small NVIDIA wglCreateContextAttribsARB Bug?

[mark ds]

Hi

Easy enough to work around, but I thought I'd report it...

wglCreateContextAttribsARB always fails to create a 3.1/3.0/2.1 context when I include WGL_CONTEXT_PROFILE_MASK_ARB, irrespective of whether I use WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB or WGL_CONTEXT_CORE_PROFILE_BIT_ARB.


int attributes[] =
{
WGL_CONTEXT_MAJOR_VERSION_ARB, majorVersion,
WGL_CONTEXT_MINOR_VERSION_ARB, minorVersion,
WGL_CONTEXT_PROFILE_MASK_ARB, coreProfile ? WGL_CONTEXT_CORE_PROFILE_BIT_ARB : WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB,
0
};

The spec states:

The attribute name WGL_CONTEXT_PROFILE_MASK_ARB requests an OpenGL context supporting a specific <profile> of the API. If the WGL_CONTEXT_CORE_PROFILE_BIT_ARB bit is set in the attribute value, then a context implementing the <core> profile of OpenGL is returned. If the WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB bit is set, then a context implementing the <compatibility> profile is returned. If the requested OpenGL version is less than 3.2, WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality of the context is determined solely by the requested version.

Obviously it isn't being ignored but causes context creation to fail. It works fine if I comment out WGL_CONTEXT_PROFILE_MASK_ARB.


int attributes[] =
{
WGL_CONTEXT_MAJOR_VERSION_ARB, majorVersion,
WGL_CONTEXT_MINOR_VERSION_ARB, minorVersion,
//WGL_CONTEXT_PROFILE_MASK_ARB, coreProfile ? WGL_CONTEXT_CORE_PROFILE_BIT_ARB : WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB,
0
};

This behaviour is true for the last two release drivers.

Regards

[mark ds]

Actually, I have found another, related, bug.


ERROR_INVALID_PROFILE_ARB is defined as 0x2096. However, GetLastError() is returning 0xC0072096 - the high word contains the extra 0xC007 instead of 0x0000.

[Aleksandar]

It is a known bug. It persists since the introduction of profiles. You shouldn't use profiles on pre-GL3.2 contexts for NV drivers.

[mark ds]

Thanks

Is the ERROR_INVALID_PROFILE_ARB also a known bug? For testing purposes I was trying to create a GL 4.4 context, and trap the errors.

At the moment I'm...



wglCreateContextAttribsARB
DWORD error = GetLastError() & 0xFFFF;
switch( error )
{
...
}


...which is all very well, but if new error codes are introduced above 0xFFFF my (generic) error code will fail! *sigh*

[mark ds]

Incidently, does anyone know if AMD drivers handle the code correctly? Or do I need to create code to handle both vendors?

[Aleksandar]

Try to use debug_output to get more details about the error. New drivers are more descriptive.
AMD usually tightly adheres to specification, but I cannot confirm it now since I don't have any AMD's GPUs.

Why are you setting GL version explicitly? Get the highest supported version and set it for the context.

[mark ds]

I'm trying to create a 4.2 core profile, with a fall back to 3.0.

At the same time, I'm trying to create a very robust framework which is capable of catching and reporting all possible errors, and handling them gracefully - which is how I discovered the driver bugs.

I will use debug_output, although it's fairly obvious what's going on - it's just a pain having to handle errors differently for each vendor... I was kinda hoping they'd follow the spec as written!!!

Thanks again.

[Alfonse Reinheart]

Incidently, does anyone know if AMD drivers handle the code correctly?

... what does it matter? If you do it the way NVIDIA wants you to, it will automatically work on AMD drivers.


I was kinda hoping they'd follow the spec as written!!!

NVIDIA treats the OpenGL specification as a suggestion to be ignored whenever it is inconvenient for them. AMD treats the OpenGL specification as something they'll get around to eventually. Intel treats the OpenGL specification as something handy to wipe themselves with after a trip to the john.

If you want to maintain your sanity, it's best to drop this "catching and reporting all possible errors" thing. Just catch the errors you actually are making, not the ones you might make. Don't try to find every possible path that fails; just fine the path that works everywhere.

[mark ds]

You're probably right.

Thanks