Necessità di cambiamento
Per molto tempo, le OpenGL si erano basate su una tecnica chiamata pbuffers per renderizzare le texture, ma tutti i programmatori erano d'accordo sul fatto che questa tecnica fosse mal concepita, difficile da usare, e che offrisse basse prestazioni. Quindi, ATI propose una nuova estensione per rimpiazzarla, l' über-buffers, una soluzione molto ambiziosa: oltre a renderizzare le texture, ATI voleva rendere possibile il rendering di un insieme di vertici, assieme ad altre funzionalità. Questa proposta era talmente ambiziosa che fu necessario molto tempo solo per definirla; nel frattempo, i programmatori divennero impazienti, e nVidia e 3DLabs fecero una controproposta in grado, quantomeno, di offrire un rendering efficiente delle texture, senza l'approccio generico della soluzione ATI. Alla fine passarono diversi anni prima di vedere dei risultati - in forma di un'estensione chiamata frame buffer_objects, che offriva le funzionalità basilari già presenti nelle DirectX 9.
Nel 2005 le OpenGL sono riuscite a riacciuffare le API di Microsoft, rilasciate tre anni prima. Tutti i principali produttori (ATI, nVidia, 3DLabs, e gli sviluppatori software) erano d'accordo che le cose non potevano andare in questa maniera, e che le OpenGL sarebbero andate a poco a poco verso l'obsolescenza. In questo contesto, l' ARB passò la staffetta a Khronos, nel 2006, lasciando nelle mani del gruppo il futuro delle OpenGL. ATI e nVidia promisero di lasciare da parte la loro rivalità e di collaborare, cosicché l'OpenGL potesse finalmente entrare nel 21esimo secolo. Gli sviluppatori furono entusiasti, poiché Khronos dimostrò di essere molto efficiente nella gestione dell'OpenGL ES, le API 3D per le periferiche mobile.
Molto velocemente, il Khronos Group iniziò a pubblicare varie comunicazioni sul futuro delle OpenGL. Il piano era ancora una volta basato sulla ristrutturazione della API in due stadi. La prima revisione, Longs Peak, avrebbe dovuto offrire un livello all'altezza dei chip grafici R300/NV30, alla pari con lo Shader Model 2, un modello di programmazione più flessibile. Un po' come le OpenGL 2.0, che 3DLabs propose anni prima, Khronos aveva pianificato di eliminare gli aspetti delle API considerati obsoleti, concentrandosi su un ristretto numero di funzioni più moderne. Questo sottoinsieme era chiamato OpenGL "Lean and Mean". La seconda principale revisione, nome in codice Mount Evans, doveva correggere i problemi delle API e aggiungere la compatibilità con R600/G80 (Shader Model 4.0). La tabella di marcia era molto veloce, con l'arrivo di Mount Evans pianificato a meno di sei mesi da Longs Peak. Ma i membri di Khronos sembravano fiduciosi.
Diversamente da ARB, Khronos decise anche di comunicare più apertamente. Una newsletter informativa era disponibile sul sito dell'OpenGL, e permetteva di iniziare a informare ed istruire gli sviluppatori sulle nuove API, permettendo loro anche di dare le proprie impressioni, fornendo un feedback importante. Tutto sembrava andare per il meglio, fino alla fine del 2007: nel settembre di quell'anno, infatti, avrebbero dovuto vedere la luce le specifiche finali di Long Peaks. Purtroppo il gruppo Khronos annunciò un ritardo, dovuto a problemi non meglio specificati; anche l'impegno di una comunicazione più aperta, preso qualche mese prima, era andato a farsi benedire, e Khronos continuò il suo lavoro all'oscuro. Nessuna nuova newsletter, e nessuna informazione sul progresso delle API.