OpenGL ES : ce que c'est, architecture et application

Qu'est-ce qu'OpenGL ES ?

OpenGL ES (Open Graphics Library for Embedded Systems) est un sous-ensemble de l'API OpenGL de bureau adapté aux appareils mobiles, aux consoles de jeux et aux systèmes embarqués. La spécification est développée par le consortium Khronos Group et est disponible gratuitement pour tous les fabricants. Contrairement à OpenGL de bureau, OpenGL ES supprime les fonctions obsolètes du pipeline fixe, ne laissant que le pipeline programmable de shaders — cela réduit la consommation d'énergie et simplifie les pilotes.

Le principal domaine d'application d'OpenGL ES est le rendu graphique en temps réel. L'API est utilisée dans les jeux mobiles (Unity, Unreal Engine), les applications de navigation, les solutions de RA basées sur ARCore et ARKit, ainsi que dans les interfaces système Android et iOS. Selon StatCounter, 2026, la part des appareils prenant en charge OpenGL ES 3.0+ dépasse 92 % parmi les smartphones actifs.

L'avantage clé d'OpenGL ES est la compatibilité multiplateforme. La même application écrite avec OpenGL ES peut fonctionner sur Android, iOS, Linux et Windows avec des modifications minimes. Cela fait de l'API un choix optimal pour les projets ciblant plusieurs plateformes sans réécrire le moteur graphique.

Pipeline fixe vs programmable

Les premières versions d'OpenGL (avant 2.0) utilisaient un pipeline fixe — un ensemble d'étapes prédéfinies de traitement des vertex et des pixels. Le développeur ne pouvait que configurer des paramètres : positions des sources de lumière, propriétés des matériaux, matrices de transformation. Pipeline programmable, introduit dans OpenGL ES 2.0, a remplacé les étapes fixes par des shaders — de petits programmes exécutés sur le GPU. Cela a donné aux développeurs un contrôle total sur le rendu de la géométrie.

La transition vers le pipeline programmable a été une révolution pour les graphiques mobiles. Les développeurs ont obtenu la capacité d'implémenter des effets complexes : PBR (Physically Based Rendering), ombres dynamiques, post-traitement et HDR. Le pipeline fixe nécessitait moins de code mais ne permettait pas de créer des styles visuels uniques. Les jeux mobiles modernes fonctionnent entièrement sur le pipeline programmable.

Architecture d'OpenGL ES : pipeline de rendu

Pipeline graphique d'OpenGL ES se compose de plusieurs étapes séquentielles, chacune transformant les données d'entrée sur le chemin des vertex aux pixels à l'écran. Comprendre l'architecture du pipeline est essentiel pour optimiser les performances de rendu sur les appareils mobiles avec un budget énergétique et thermique limité.

La première étape — le vertex shader — traite chaque vertex indépendamment. À cette étape, les transformations sont appliquées : passage de l'espace local du modèle à l'espace monde, puis à l'espace caméra et enfin à l'espace de découpage (clip space). Transformations sont définies via des matrices uniformes MVP (Model-View-Projection), qui sont mises à jour à chaque image lors du déplacement de la caméra ou des objets.

Après l'assemblage des primitives (points, lignes, triangles), la rastérisation est effectuée — le processus de détermination des pixels de l'écran que chaque primitive couvre. Rastériseur génère des fragments — pixels potentiels avec des attributs interpolés (couleur, normales, coordonnées UV). Le nombre de fragments dépend directement de la résolution de l'écran et de la surface de projection de la primitive.

Le fragment shader est exécuté pour chaque fragment généré. Il calcule la couleur finale du pixel en tenant compte des textures, des sources de lumière et des matériaux. La sortie du fragment shader passe par une série de tests par fragment : le depth test détermine si le fragment est visible ; le stencil test restreint le rendu par masque ; le blending mélange la couleur du fragment avec la couleur déjà écrite dans le framebuffer.

États du contexte OpenGL ES

OpenGL ES fonctionne comme une machine d'états : tous les paramètres — shader actuel, textures liées, tests activés — sont stockés dans l'état global du contexte. Changer l'état via glEnable, glBindTexture ou glUseProgram affecte toutes les commandes de dessin suivantes. Chaque changement d'état entraîne une surcharge dans le pilote, donc regrouper les appels de dessin par état est la principale technique d'optimisation.

Versions d'OpenGL ES et leurs capacités

OpenGL ES 1.0 et 1.1 (sortis en 2003–2004) étaient basés sur un pipeline fixe. Ils prenaient en charge les transformations, la texturation, l'éclairage et le blending, mais ne permettaient pas de programmer des shaders. L'API était utilisée dans les premiers téléphones mobiles et les appareils basés sur Symbian et Windows Mobile. Aujourd'hui, ces versions sont considérées comme obsolètes — les appareils modernes ne les supportent pas.

OpenGL ES 2.0 (2007) a introduit un pipeline programmable avec des shaders de vertex et de fragment en GLSL ES. Cette version est devenue la norme pour Android 2.2+ et iOS 5+ et est encore supportée par la grande majorité des appareils. OpenGL ES 2.0 est la version minimale requise pour Unity, Unreal Engine et Cocos2d-x sur les plateformes mobiles.

OpenGL ES 3.0 (2012) a ajouté plusieurs capacités critiques : plusieurs render targets (MRT), transform feedback, instancing, textures de format arbitraire via ETC2/EAC. Les performances de rendu ont augmenté de 30 à 50 % par rapport à la version 2.0 en réduisant le nombre d'appels de dessin. OpenGL ES 3.1 (2014) a introduit les shaders de calcul et les opérations atomiques sur les buffers — cela a permis d'exécuter sur le GPU non seulement des tâches graphiques mais aussi de calcul (post-traitement, simulation de tissus, calcul physique).

OpenGL ES 3.2 (2015) — la dernière version de la spécification — a ajouté les shaders de tessellation et de géométrie, ainsi qu'un ensemble étendu de textures float et de modes de blending. Malgré la sortie du plus moderne Vulkan en 2016, OpenGL ES 3.2 reste une API pertinente grâce à l'énorme base de code existante et à la facilité de portage des applications entre plateformes.

Shaders dans OpenGL ES : GLSL et pipeline programmable

GLSL ES (OpenGL Shading Language for Embedded Systems) est un langage de programmation de shaders basé sur la syntaxe C avec des types supplémentaires pour travailler avec des vecteurs et des matrices. Chaque shader est un programme compilé en code machine GPU lors de l'initialisation de l'application. Contrairement au code CPU, les shaders s'exécutent massivement en parallèle : des milliers de vertex ou de fragments sont traités simultanément.

Vertex shaders

Vertex shader traite chaque vertex du maillage. Sa tâche principale est de calculer la position finale du vertex dans le clip space en multipliant la position d'entrée par la matrice MVP. De plus, le vertex shader peut calculer les normales, les coordonnées UV, les couleurs et les transmettre au fragment shader via des variables varying. Chaque invocation du vertex shader fonctionne indépendamment, permettant au GPU de traiter des millions de vertex par image.

// Simple vertex shader for OpenGL ES 3.0
#version 300 es
layout(location = 0) in vec4 a_position;
layout(location = 1) in vec3 a_normal;
layout(location = 2) in vec2 a_texCoord;

uniform mat4 u_mvpMatrix;

out vec3 v_normal;
out vec2 v_texCoord;

void main() {
    gl_Position = u_mvpMatrix * a_position;
    v_normal = mat3(u_mvpMatrix) * a_normal;
    v_texCoord = a_texCoord;
}

Fragment shaders

Fragment shader détermine la couleur de chaque pixel à l'écran. Il reçoit des valeurs varying interpolées du vertex shader, échantillonne des texels des textures liées et applique l'éclairage. Pour un éclairage correct, le modèle de Phong ou Blinn-Phong est utilisé avec le calcul des composantes diffuse, specular et ambient. Chaque invocation du fragment shader correspond à un pixel, donc le nombre total d'invocations est égal à la surface de projection de l'objet à l'écran.

// Simple fragment shader with texture and lighting
#version 300 es
precision mediump float;

in vec3 v_normal;
in vec2 v_texCoord;

uniform sampler2D u_texture;
uniform vec3 u_lightDir;

out vec4 fragColor;

void main() {
    vec4 texel = texture(u_texture, v_texCoord);
    vec3 normal = normalize(v_normal);
    float diffuse = max(dot(normal, u_lightDir), 0.0);
    fragColor = vec4(texel.rgb * diffuse, texel.a);
}

Dans l'exemple ci-dessus, le fragment shader échantillonne un texel d'une texture 2D par coordonnées UV, calcule l'éclairage diffus comme le produit scalaire de la normale et de la direction de la lumière, et multiplie la couleur du texel par l'intensité de l'éclairage. Mediump est la précision recommandée pour les fragment shaders sur GPU mobiles : elle fournit une qualité suffisante avec une consommation d'énergie minimale.

Comment commencer à travailler avec OpenGL ES dans les projets mobiles

Pour travailler avec OpenGL ES sur Android, il est nécessaire de créer un contexte EGL — une surface sur laquelle les graphiques seront rendus. Sur iOS, la couche EAGL (similaire à EGL) fournie par le framework GLKit est utilisée. Dans les deux cas, le processus d'initialisation comprend la création d'une surface de fenêtre, la configuration des attributs du contexte et la liaison au thread de rendu actuel.

// OpenGL ES 3.0 initialization on Android
class MyGLRenderer : GLSurfaceView.Renderer {

    private val vertexShaderCode = "#version 300 es\n..."
    private val fragmentShaderCode = "#version 300 es\n..."

    override fun onSurfaceCreated(gl: GL10?, config: EGLConfig?) {
        GLES30.glClearColor(0.1f, 0.1f, 0.2f, 1.0f)
        GLES30.glEnable(GLES30.GL_DEPTH_TEST)
    }

    override fun onDrawFrame(gl: GL10?) {
        GLES30.glClear(GLES30.GL_COLOR_BUFFER_BIT or GLES30.GL_DEPTH_BUFFER_BIT)
        // bind VBO, set uniforms, draw elements
    }

    override fun onSurfaceChanged(gl: GL10?, width: Int, height: Int) {
        GLES30.glViewport(0, 0, width, height)
    }
}

Après la création du contexte, le développeur doit configurer les buffers : le buffer de vertex (VBO) contient les coordonnées des vertex, les normales et les UV ; le buffer d'indices (EBO) définit l'ordre de parcours des vertex pour former les triangles. VAO (Vertex Array Object) combine la configuration de tous les attributs en un seul objet, réduisant le nombre d'appels API lors du changement de maillage.

Configuration du contexte EGL

EGL (Native Platform Graphics Interface) est une couche intermédiaire entre OpenGL ES et le système de fenêtres. Sur Android, EGL gère la création de la surface de rendu, la sélection de la configuration du framebuffer (profondeur de couleur, stencil, MSAA) et la synchronisation avec vsync. Une configuration typique demande du RGBA8888 avec un buffer de profondeur 24 bits et un buffer stencil 8 bits. Sur iOS, le rôle d'EGL est assuré par EAGL en conjonction avec CAEAGLLayer.

L'optimisation des performances d'OpenGL ES sur les appareils mobiles comprend plusieurs pratiques clés. Utilisez l'instancing (glDrawArraysInstanced) pour rendre de nombreux objets identiques — cela réduit le nombre d'appels de dessin. Appliquez des pools de textures et évitez de changer de texture entre les appels de dessin. Triez les objets par shader, puis par texture, puis par maillage — cet ordre minimise les changements d'état du contexte.

OpenGL ES vs Metal vs Vulkan

Metal est une API graphique bas niveau d'Apple, disponible sur iOS et macOS à partir de la puce A7. Metal fournit un accès direct au GPU avec une surcharge minimale du pilote, mais fonctionne uniquement sur les appareils Apple. Selon WWDC 2024, Metal offre jusqu'à 40 % de performances supérieures par rapport à OpenGL ES sur le même matériel en réduisant les vérifications d'état à l'exécution.

Vulkan est le successeur multiplateforme d'OpenGL ES, développé par Khronos Group. Vulkan utilise une gestion explicite des ressources : le développeur alloue des pools de mémoire, crée des buffers de commandes et synchronise l'accès au GPU. Cela donne un contrôle maximal sur les performances, mais le code d'initialisation de Vulkan est 3 à 4 fois plus volumineux que celui d'OpenGL ES. Vulkan est recommandé pour les jeux AAA et les applications graphiques exigeantes sur Android 7+.

Le choix entre OpenGL ES, Metal et Vulkan dépend des plateformes cibles et des exigences de performances. OpenGL ES reste le meilleur choix pour les projets multiplateformes où la vitesse de développement est importante. Metal est préféré pour l'écosystème iOS/macOS avec des performances maximales. Vulkan est le choix pour les projets où chaque milliseconde par image compte et où le budget de développement permet d'investir dans l'optimisation bas niveau.