Unexpected pipeline recompilation on glEnable/glDisable in low-traffic OpenGL workloads

The short answer

There is no glEnable/glDisable combination that is guaranteed not to trigger pipeline revalidation across major desktop drivers. The OpenGL specification deliberately leaves validation timing implementation-dependent: a driver may validate eagerly at the state-change call, lazily at draw time, or anywhere in between, and the policy varies by vendor, driver version, and even the currently bound program. So the honest answer to your first question is: none — and code that assumes otherwise is non-portable.

Core profile does not remove validation

Creating a core profile context with explicit shader programs eliminates the fixed-function pipeline and its associated legacy state, but it does not eliminate driver-side validation of the programmable pipeline. Capabilities like GL_BLEND, GL_DEPTH_TEST, GL_CULL_FACE, GL_SCISSOR_TEST, and GL_STENCIL_TEST still exist in core profile, and toggling them can still cause the driver to re-validate or re-specialize internal pipeline state. Core profile shrinks the state surface; it doesn't make state changes free.

glGetIntegerv cannot observe recompilation

No. Standard state queries return the values you set, not what the driver did in response. There is no portable OpenGL query that reports "this state change triggered a recompile/revalidation." The only way to detect it is externally: measure CPU time around the calls or draws, or use vendor profiling tools to watch driver CPU usage and pipeline state changes per frame.

What this means for your low-traffic scene

Since you can't rely on guarantees, the practical strategy is to make the question moot:

1. Sort and batch state changes. Group draws by required state so each capability is toggled at most once per frame, ideally once ever.
2. Prefer state objects. VAOs, FBOs, and sampler objects collapse many state changes into one bind, which is cheaper to validate than scattered enables.
3. Avoid redundant toggles. Track current state in your application and skip no-op glEnable/glDisable calls — some drivers still pay a cost even for redundant calls.
4. Move state into shaders where possible. For example, a branch on a uniform can sometimes replace a blend-mode toggle, at the cost of shader complexity.

Verifying on your actual driver

Because behavior is version-sensitive, measure on the target hardware rather than trusting general claims:

// Time the suspicious region with a high-resolution timer
auto t0 = std::chrono::steady_clock::now();
glEnable(GL_BLEND);
// ... draws ...
auto t1 = std::chrono::steady_clock::now();

Then compare a version of the frame with the toggles hoisted out against the toggling version. On the vendor side, tools like NVIDIA Nsight, AMD Radeon GPU Profiler, or Intel GPA can show driver CPU time and pipeline state changes per frame. If the delta disappears when toggles are removed, validation cost was your bottleneck; if not, look at synchronization or resource binding instead — recompilation is often blamed for spikes actually caused by buffer uploads or implicit sync.

One caveat worth flagging: everything above about specific driver behavior is general, well-established knowledge, not a measurement of your setup. If you can share the vendor, driver version, and GPU, the recommendation on which capabilities to prioritize batching could be more specific.