GL_DEBUG_SEVERITY_HIGH missing for GL_INVALID_OPERATION on some drivers — glDebugMessageCallback filtering

Short answer

Severity is not normative. The KHR_debug / OpenGL 4.3 specification deliberately leaves severity assignment to the implementation, so the same GL_INVALID_OPERATION can legitimately arrive as GL_DEBUG_SEVERITY_HIGH on one driver and MEDIUM or even LOW on another. Filtering on HIGH alone will silently drop real errors on some vendors. The portable basis for your filter is the type enum, not severity.

Does GL_DEBUG_TYPE_ERROR correspond to a glGetError error?

Mostly yes, with caveats. GL_DEBUG_TYPE_ERROR messages are generated when the implementation detects an API error condition, and those are the same conditions the spec defines as setting the glGetError error flag. So in practice a TYPE_ERROR message corresponds to a glGetError-reportable error.

However, the spec does not guarantee:

• that every error produces exactly one message (a driver may emit several, or batch them),
• the ordering of messages relative to glGetError,
• that the error flag you read inside the callback is the same error the message describes — the flag is sticky per context and may have been set by an earlier unchecked call.

So treat TYPE_ERROR as "an API error occurred at or before this point," not as a 1:1 mapping to a specific glGetError return value.

Is severity classification normative?

No. Drivers may legitimately downgrade severity for errors they consider benign, and may emit performance hints or undefined-behavior warnings at any severity they choose. There is no cross-vendor severity table you can rely on, and message IDs and message strings are explicitly vendor-specific — never parse the string for classification.

Recommended portable filter

1. Accept messages of type GL_DEBUG_TYPE_ERROR and GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR. Type classifications are applied far more consistently across NVIDIA, AMD, and Intel than severities.
2. Use glDebugMessageControl to enable all messages of those types regardless of severity — pass GL_DONT_CARE for source, severity, and id. This is the portable way to avoid per-vendor ID tables.
3. Optionally restrict source to GL_DEBUG_SOURCE_API to exclude driver-internal or third-party chatter.
4. Use severity only as a display priority hint within accepted types, never as an inclusion criterion.

// Enable all ERROR and UNDEFINED_BEHAVIOR messages, any severity/source/id
glDebugMessageControl(GL_DONT_CARE, GL_DEBUG_TYPE_ERROR,
                      GL_DONT_CARE, 0, nullptr, GL_TRUE);
glDebugMessageControl(GL_DONT_CARE, GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR,
                      GL_DONT_CARE, 0, nullptr, GL_TRUE);

Verification

With GL_DEBUG_OUTPUT_SYNCHRONOUS enabled, the callback fires on the calling thread at the offending call, so you can empirically confirm behavior per driver:

1. Create a debug core context (e.g., GLFW_OPENGL_DEBUG_CONTEXT). Without GL_CONTEXT_FLAG_DEBUG_BIT, some drivers emit nothing at all — absence of messages is not proof of correctness.
2. Deliberately trigger GL_INVALID_OPERATION (e.g., glUseProgram with a non-program id) and record the delivered type/severity on each vendor.
3. Inside the callback, call glGetError and confirm it returns the matching enum for TYPE_ERROR messages.

Two practical cautions: synchronous output serializes the pipeline and can hurt performance, so enable it only in diagnostic builds; and if your layer must report the exact failing enum, capture it via glGetError in the callback rather than inferring it from the message.