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

Minimizing CPU overhead for a low-traffic OpenGL scene that issues only a handful of draw calls per frame is the primary goal. The OpenGL specification does not define when drivers recompile pipeline stages after state changes, leaving the behavior implementation-dependent. Some drivers recompile on every glEnable/glDisable call, while others batch validation until draw time. For workloads with minimal draw calls, this recompilation cost can dominate frame time, yet the exact triggers and thresholds remain undocumented.

• Which glEnable/glDisable combinations are guaranteed not to trigger pipeline recompilation on major desktop drivers?
• Does using a core profile context with explicit shader programs eliminate the legacy state validation path entirely?
• Can glGetIntegerv queries reliably indicate whether a state change caused recompilation?