Pourquoi une carte graphique contient un GPU, et non un CPU

Un processeur central est construit pour terminer une tâche le plus vite possible. Un processeur graphique est construit pour en terminer des millions à la fois. Cette page montre, chiffres et lois à l'appui, que cette différence n'est pas un choix de fabricant mais une conséquence de la nature même du calcul d'une image.

Niveau visé : fin de secondaire scientifique à première année d'université. Les caractéristiques techniques proviennent des fiches des constructeurs et des publications citées en fin de page ; les calculs d'ordre de grandeur sont détaillés avec leurs hypothèses pour pouvoir être refaits. Page rédigée en septembre 2026.

L'essentiel en cinq points

Une image est faite de millions de pixels dont la couleur se calcule indépendamment : le rendu est un problème « massivement parallèle ».
Un CPU est optimisé pour la latence (finir vite une tâche) ; un GPU pour le débit (finir beaucoup de tâches par seconde).
Cette différence se lit dans le silicium : le CPU dépense ses transistors en caches et en logique de contrôle, le GPU en unités de calcul.
Le rendu consomme surtout de la bande passante mémoire ; une carte graphique en offre dix à vingt fois plus qu'un ordinateur de bureau.
Certaines étapes (filtrage des textures, rasterisation, tests de profondeur) sont dix à quarante fois plus efficaces dans des circuits dédiés que dans du code exécuté par un processeur généraliste.

Une image, ce sont des millions de petits calculs identiques

Ce que le rendu d'une scène en trois dimensions demande à la machine

Un écran affiche une grille de points colorés, les pixels. Pour chaque image, la machine doit décider de la couleur de chacun d'eux, puis recommencer soixante, cent vingt ou cent quarante-quatre fois par seconde selon le taux de rafraîchissement. Le tableau ci-dessous donne les ordres de grandeur pour les définitions courantes. Le nombre de pixels est le produit exact de la largeur par la hauteur ; les débits sont arrondis au dixième de million.

Tableau 1 — Nombre de pixels à colorer par seconde, selon la définition et le taux de rafraîchissement
Définition	Pixels par image	À 60 Hz (M px/s)	À 120 Hz (M px/s)	À 144 Hz (M px/s)
1920 × 1080 (« Full HD »)	2 073 600	124,4	248,8	298,6
2560 × 1440 (« QHD »)	3 686 400	221,2	442,4	530,8
3840 × 2160 (« 4K UHD »)	8 294 400	497,7	995,3	1 194,4

Le temps disponible pour chaque image est l'inverse du taux de rafraîchissement : 1/60 s = 16,67 ms, 1/120 s = 8,33 ms, 1/144 s = 6,94 ms. Cette contrainte est stricte : une image qui n'est pas prête à temps est simplement affichée en retard, ce que l'œil perçoit comme une saccade. Le rendu n'est donc pas seulement un problème de débit moyen, mais aussi de latence bornée à l'échelle de l'image entière.

Que signifie « calculer un pixel » ?

Une scène en trois dimensions est décrite par des sommets (les coins de triangles), des matériaux et des lumières. La transformer en image se fait en une suite d'étapes qu'on appelle le pipeline graphique. La figure 1 en donne la version simplifiée qui est commune, à quelques détails près, à toutes les cartes graphiques depuis 2001.

Figure 1. Chaque triangle est projeté sur l'écran (vertex shader), découpé en « fragments » candidats à devenir des pixels (rasterisation), colorié (fragment shader), puis soumis aux tests de profondeur et de mélange (ROP, raster operations) avant d'être écrit dans l'image. Le pipeline réel comporte d'autres étapes optionnelles (tessellation, géométrie, calcul) qui ne changent pas le raisonnement.

Un fragment n'est pas encore un pixel : quand plusieurs surfaces se superposent, plusieurs fragments visent le même pixel et seul le plus proche survit au test de profondeur. Ce surdessin (overdraw) fait que le nombre de fragments coloriés par image dépasse le nombre de pixels. Il faut y ajouter les passes auxiliaires (cartes d'ombres calculées du point de vue de chaque lumière, réflexions, post-traitement, anticrénelage) : dans un jeu contemporain, le travail par image représente couramment plusieurs fois le nombre de pixels de l'écran.

La propriété décisive : les pixels sont indépendants

Le point capital n'est pas la quantité de calcul, mais sa structure. Dans une passe de rendu, la couleur d'un fragment ne dépend pas du résultat du calcul de ses voisins ; elle dépend seulement de la scène, des lumières et de la position du fragment. De même, chaque sommet est projeté indépendamment des autres. Le même programme s'exécute donc des millions de fois sur des données différentes, sans qu'aucune exécution ait à attendre une autre. Dans la classification de Flynn (1966, 1972), c'est le cas « une instruction, plusieurs données » (SIMD). Les informaticiens qualifient ce type de problème de trivialement parallèle (embarrassingly parallel) : on peut le découper en autant de morceaux qu'on veut sans coût de coordination.

À l'inverse, la logique d'un jeu (résoudre les collisions dans l'ordre, appliquer les règles, réagir aux entrées du joueur) forme une chaîne d'opérations dont chacune dépend de la précédente. On ne peut pas la découper à volonté. Ces deux structures de calcul appellent deux machines différentes, et c'est tout l'objet des chapitres suivants.

Exemple chiffré : un budget pour la 4K à 120 Hz. Les hypothèses sont notées H1 à H3 ; elles sont des ordres de grandeur, non des mesures, et le lecteur peut les modifier pour refaire le calcul.

Fragments à colorier. 8 294 400 pixels × 120 images/s = 995 328 000 fragments/s, au minimum (sans surdessin).
H1 — arithmétique par fragment : 300 opérations flottantes 32 bits (un programme d'éclairage physiquement réaliste en compte quelques centaines). Soit 995,3 × 10⁶ × 300 ≈ 0,30 × 10¹² opérations/s (0,30 TFLOP/s).
H2 — surdessin et passes auxiliaires : facteur 4. Le besoin monte à environ 1,2 TFLOP/s soutenus pendant toute la seconde, et répartis uniformément sur chaque tranche de 8,33 ms.
H3 — textures : 8 lectures de texture par fragment, chacune interpolant 4 texels de 4 octets. Soit 128 octets par fragment, donc 995,3 × 10⁶ × 4 × 128 ≈ 510 Go/s de lectures brutes. Les caches en absorbent la majeure partie grâce à la localité spatiale des textures ; en supposant qu'ils en absorbent 90 %, il reste 51 Go/s à fournir par la mémoire principale, avant de compter la géométrie, les tampons de profondeur et l'image elle-même.

Le chapitre 4 comparera ces besoins aux capacités d'un processeur de bureau à seize cœurs (crête d'environ 4,4 TFLOP/s, bus mémoire de 89,6 Go/s) et d'une carte graphique de 2022 (82,6 TFLOP/s, 1 008 Go/s). Sur le papier, le processeur semble tenir le débit arithmétique à condition d'y consacrer un quart de sa puissance de crête ; on verra pourquoi cette crête est inatteignable sur ce type de travail, et pourquoi la carte graphique, elle, n'en utilise qu'un ou deux pour cent.

Le processeur central est une machine à réduire la latence

Pourquoi un CPU dépense l'essentiel de ses transistors à autre chose que calculer

Le processeur central (CPU, central processing unit) exécute le système d'exploitation, les navigateurs, les compilateurs, la logique des jeux : des programmes faits de longues chaînes d'instructions dont chacune dépend souvent du résultat de la précédente, avec des branchements imprévisibles et des accès mémoire irréguliers. Sur ce type de programme, il n'y a pas des millions de tâches indépendantes à traiter en même temps ; il y en a une, ou quelques-unes, et la seule façon d'aller plus vite est de raccourcir le temps de chaque étape. Le CPU est donc conçu pour minimiser la latence d'un flux d'instructions unique. Toute son architecture découle de cet objectif.

Les outils du CPU

Fréquence élevée. Un cœur de bureau moderne cadence ses instructions entre 4 et 6 GHz (le Ryzen 9 9950X d'AMD, sorti en 2024, annonce 4,3 GHz de base et 5,7 GHz en pointe). Chaque cycle dure moins de 0,25 ns.
Exécution superscalaire et dans le désordre. Le cœur décode plusieurs instructions par cycle (jusqu'à huit sur Zen 5), les réordonne pour exécuter celles dont les opérandes sont prêts, et remet les résultats dans l'ordre du programme. Le principe remonte à l'algorithme de Tomasulo (1967). Cette machinerie de réordonnancement représente une part importante de la surface du cœur.
Prédiction de branchement et exécution spéculative. Avant de savoir si une condition est vraie, le cœur parie sur l'issue et continue ; les prédicteurs modernes se trompent dans moins de cinq pour cent des cas sur du code ordinaire. Une erreur coûte une vingtaine de cycles pour vider le pipeline.
Hiérarchie de caches. La mémoire principale (DRAM) répond en 80 à 100 ns, soit 400 à 500 cycles : une éternité. Le CPU garde donc près de lui des copies des données récentes dans des caches à plusieurs niveaux. Le 9950X embarque 16 Mo de cache L2 et 64 Mo de L3, soit 80 Mo au total, et des préchargeurs qui devinent les prochains accès.

Le résultat est un cœur très rapide sur une tâche isolée, mais dont la majeure partie de la surface et de la consommation sert à organiser le calcul plutôt qu'à le faire. Horowitz (2014) a chiffré les coûts énergétiques élémentaires en technologie 45 nm : une addition flottante 32 bits coûte environ 0,9 pJ, une multiplication 3,7 pJ, une lecture en DRAM d'un mot de 32 bits environ 640 pJ, soit quelque 700 fois l'addition. Dally et ses collègues (2008) estimaient que, sur un processeur généraliste, l'énergie dépensée pour acheminer, décoder et ordonnancer une instruction dépasse d'un à deux ordres de grandeur celle de l'opération arithmétique qu'elle commande. Autrement dit, sur un CPU, l'arithmétique elle-même est presque gratuite ; ce qui coûte, c'est tout ce qui l'entoure.

Figure 2. Schéma qualitatif, inspiré de la figure du guide de programmation CUDA de NVIDIA : les proportions ne sont pas à l'échelle. À gauche, un cœur de CPU consacre l'essentiel de sa surface au contrôle et aux caches pour servir vite un seul flux d'instructions. À droite, un GPU aligne des unités de calcul (« ALU », arithmetic logic unit) par milliers et partage la logique de contrôle entre elles par groupes de 32.

La réponse du CPU au parallélisme de données : les instructions vectorielles

Les concepteurs de CPU n'ignorent pas le calcul sur tableaux. Depuis les années 1990, chaque cœur possède des instructions SIMD qui appliquent une opération à plusieurs nombres rangés côte à côte dans un registre large : 4 flottants 32 bits avec SSE (128 bits), 8 avec AVX (256 bits), 16 avec AVX-512 (512 bits). Une instruction de multiplication-addition fusionnée (FMA) compte pour deux opérations flottantes par voie. On peut donc calculer la puissance de crête d'un CPU exactement comme celle d'un GPU :

crête = (cœurs) × (opérations par cycle et par cœur) × (fréquence)

Pour le Ryzen 9 9950X, dont chaque cœur Zen 5 exécute deux FMA de 512 bits par cycle, soit 2 × 16 × 2 = 64 opérations flottantes 32 bits par cycle : 16 × 64 × 4,3 × 10⁹ ≈ 4,4 × 10¹² opérations/s (4,4 TFLOP/s) à la fréquence de base, et 5,8 TFLOP/s à la fréquence de pointe de 5,7 GHz, valeur théorique que les mesures indépendantes montrent inatteignable sur seize cœurs simultanément, la fréquence chutant de près de 2 GHz sous charge AVX-512 intensive (Yee, 2024).

Ce chiffre de crête est honnête, mais il cache trois conditions qui ne sont presque jamais réunies dans un rendu graphique :

Le code doit être parfaitement vectorisé, c'est-à-dire écrit ou compilé de façon que chaque instruction traite seize fragments à la fois, avec les mêmes branchements. Dès qu'un fragment sur seize prend un autre chemin, la voie correspondante est masquée et le débit chute.
Les données doivent arriver à temps. Une lecture de texture est un accès dispersé (gather) : seize fragments voisins lisent seize adresses différentes. Les instructions de lecture dispersée des CPU ne traitent que quelques éléments par cycle, contre une lecture filtrée complète par cycle et par unité de texture sur un GPU.
Le bus mémoire est étroit. Un processeur de bureau dialogue avec sa DDR5 sur deux canaux de 64 bits. À 5 600 mégatransferts par seconde (la vitesse officielle du 9950X), le débit théorique est 2 × 64 bits × 5 600 × 10⁶/s ÷ 8 = 89,6 Go/s. C'est onze fois moins qu'une carte graphique de 2022, et vingt fois moins qu'une de 2025 (chapitre 3).

Pourquoi un CPU ne pourrait pas utiliser un bus large même si on le lui donnait

On pourrait imaginer souder de la mémoire graphique sur un CPU pour lui offrir 1 000 Go/s. La loi de Little (1961), un résultat général de la théorie des files d'attente, montre que cela ne servirait à rien. Elle s'écrit :

N = λ × W, soit : (requêtes en cours) = (débit) × (latence).

Pour maintenir un débit de 1 000 Go/s avec une latence mémoire de l'ordre de 500 ns (hypothèse de travail pour une mémoire graphique sous charge), il faut avoir en permanence 10¹² × 5 × 10⁻⁷ = 500 000 octets « en vol », soit environ 7 800 requêtes de 64 octets en attente de réponse en même temps. Un cœur de CPU ne peut suivre que quelques dizaines de défauts de cache simultanés (ses tampons de défauts, les miss status holding registers, sont peu nombreux parce que chaque entrée est coûteuse et que le cœur compte sur ses caches pour ne pas en avoir besoin). Seize cœurs à 32 requêtes chacun donnent 512 requêtes en vol, quinze fois moins que nécessaire : le bus resterait vide les neuf dixièmes du temps. Un GPU, on va le voir, fait exactement l'inverse : il maintient des centaines de milliers de fils d'exécution prêts, dont une fraction suffit à saturer le bus.

Le processeur graphique est une machine à maximiser le débit

Quatre décisions de conception qui découlent directement de l'indépendance des pixels

Le processeur graphique (GPU, graphics processing unit) part de l'hypothèse inverse du CPU : il y a toujours des millions de tâches identiques et indépendantes à faire. Dès lors, la latence de chacune importe peu ; ce qui compte est le nombre de tâches terminées par seconde et par watt. Quatre décisions de conception en découlent, et chacune est un renoncement à quelque chose que le CPU fait bien.

Décision 1 : partager le contrôle entre 32 voies (SIMT)

Puisque des milliers de fragments exécutent le même programme, on peut n'aller chercher et décoder chaque instruction qu'une seule fois pour un groupe entier. NVIDIA appelle ce groupe un warp de 32 fils d'exécution, AMD un wavefront de 32 ou 64. Le modèle, nommé SIMT par Lindholm et ses collègues (2008), est du SIMD présenté au programmeur comme des fils d'exécution ordinaires : chaque voie a ses registres, son adresse mémoire, et le matériel masque les voies qui ne prennent pas un branchement. Le coût du contrôle est ainsi divisé par 32.

Concrètement, une GeForce RTX 4090 (2022) contient 128 multiprocesseurs (SM, streaming multiprocessors) de 128 voies FP32 chacun, soit 16 384 voies ; chaque SM comprend quatre ordonnanceurs de warps, soit 512 ordonnanceurs pour toute la puce. Le rapport est donc d'un ordonnanceur pour 32 voies, contre un ordonnanceur (bien plus complexe) pour 32 voies FMA dans un cœur Zen 5, mais avec une différence de taille : celui du GPU se contente d'émettre en ordre, sans prédiction ni spéculation.

Décision 2 : tolérer la latence au lieu de la cacher

Un CPU cache la latence de la mémoire avec de grands caches et l'exécution dans le désordre. Un GPU la tolère : quand un warp attend une donnée, l'ordonnanceur en fait avancer un autre, sans aucun coût de commutation, parce que les registres de tous les warps résidents sont physiquement présents dans le SM. Sur l'architecture Ada Lovelace de la RTX 4090, chaque SM dispose de 65 536 registres de 32 bits (256 Ko) et peut héberger jusqu'à 48 warps, soit 1 536 fils ; la puce entière en tient près de 200 000, et 32 Mo de registres. La figure 3 montre le mécanisme.

Figure 3. Quatre warps se relaient sur les mêmes unités de calcul. Chacun passe les trois quarts de son temps à attendre la mémoire, mais les unités ne chôment jamais. Avec des dizaines de warps résidents par multiprocesseur, un GPU couvre des latences de plusieurs centaines de nanosecondes sans cache de grande taille ni exécution dans le désordre.

Décision 3 : un bus mémoire aussi large que possible

Puisque le GPU est capable de garder des milliers de requêtes en vol (loi de Little, chapitre 2), il peut exploiter une mémoire très rapide, soudée sur la carte au plus près de la puce, et connectée par un bus quatre fois plus large que celui d'un CPU de bureau. Le calcul est le même que pour la DDR5 : (largeur du bus) × (débit par fil) ÷ 8.

RTX 4090 : 384 bits de GDDR6X à 21 Gbit/s par fil : 384 × 21 × 10⁹ ÷ 8 = 1 008 Go/s.
RTX 5090 (2025) : 512 bits de GDDR7 à 28 Gbit/s par fil : 512 × 28 × 10⁹ ÷ 8 = 1 792 Go/s.

Le prix de cette bande passante est une latence plus élevée que la DDR d'un CPU et une capacité fixée à la fabrication (24 Go sur la RTX 4090, 32 Go sur la RTX 5090) : la mémoire graphique ne s'agrandit pas. Un CPU ne ferait pas ce compromis, parce que ses programmes sont sensibles à la latence et parce que l'utilisateur veut pouvoir ajouter des barrettes.

Décision 4 : câbler en dur ce qui ne change jamais

Certaines étapes du pipeline (figure 1) sont exécutées des milliards de fois par seconde et n'ont pas changé depuis vingt ans. Pour elles, un circuit dédié est bien plus économe qu'un programme, parce qu'il supprime tout le coût d'instruction décrit au chapitre 2. Un GPU en contient plusieurs familles :

Le rasteriseur détermine quels pixels un triangle couvre, par évaluation de fonctions d'arête (Pineda, 1988), et interpole les attributs.
Les unités de texture (TMU, texture mapping units) calculent les adresses, choisissent le niveau de détail, décompressent les formats de texture (BC1 à BC7, ASTC) et filtrent : un filtrage bilinéaire lit 4 texels et effectue 3 interpolations par canal ; un trilinéaire en lit 8 ; un anisotrope 16× en lit jusqu'à 128. La RTX 4090 possède 512 de ces unités, la RTX 5090 en a 680 ; chacune produit une valeur filtrée par cycle, soit 512 × 2,52 × 10⁹ ≈ 1 290 milliards de lectures filtrées par seconde pour la première. Quand Intel a tenté de construire une carte graphique à partir de cœurs x86 (Larrabee, chapitre 5), ses ingénieurs ont conservé des unités de texture câblées, ayant calculé qu'en logiciel l'opération serait 12 à 40 fois plus lente selon le filtrage et la compression (Seiler et al., 2008).
Les unités de sortie (ROP) exécutent le test de profondeur, le test de pochoir, le mélange de transparence, la résolution de l'anticrénelage et la compression de l'image en mémoire : 176 unités sur les deux cartes citées.
Depuis 2018, des unités de lancer de rayons (parcours de hiérarchies de boîtes englobantes, intersection rayon-triangle) et des unités matricielles (tensor cores) qui accélèrent les produits de matrices utilisés par les réseaux de neurones.

Un CPU ne possède aucune de ces unités. Ce n'est pas un oubli : elles n'accéléreraient aucun des programmes qu'il exécute d'ordinaire, et occuperaient une surface que ses concepteurs préfèrent consacrer au cache.

Trois puces, mêmes unités de mesure

Un processeur de bureau haut de gamme et deux cartes graphiques grand public, ramenés à des grandeurs comparables

Le tableau 2 confronte un processeur de bureau de 2024 aux deux cartes graphiques haut de gamme de NVIDIA de 2022 et 2025. Le choix de NVIDIA tient uniquement à la disponibilité publique des chiffres ; une Radeon d'AMD ou une Arc d'Intel donneraient le même tableau à quelques dizaines de pour cent près. Les valeurs sont celles des fiches constructeurs ; les lignes marquées d'un astérisque sont calculées à partir d'elles selon les formules des chapitres 2 et 3.

Tableau 2 — Ryzen 9 9950X (CPU) contre GeForce RTX 4090 et RTX 5090 (GPU)
Grandeur	Ryzen 9 9950X	GeForce RTX 4090	GeForce RTX 5090
Année de sortie	2024	2022	2025
Unités indépendantes de contrôle	16 cœurs (32 fils)	512 ordonnanceurs de warps	680 ordonnanceurs de warps
Voies de calcul FP32 *	512	16 384	21 760
Fréquence	4,3 GHz (base) – 5,7 GHz	2,52 GHz (pointe)	2,41 GHz (pointe)
Crête FP32 *	4,4 TFLOP/s (à 4,3 GHz)	82,6 TFLOP/s	104,8 TFLOP/s
Mémoire	DDR5-5600, 2 × 64 bits, extensible	24 Go GDDR6X, 384 bits	32 Go GDDR7, 512 bits
Bande passante mémoire *	89,6 Go/s	1 008 Go/s	1 792 Go/s
Cache sur la puce	80 Mo (L2 + L3)	72 Mo (L2)	96 Mo (L2)
Unités de texture	0	512	680
Unités de sortie (ROP)	0	176	176
Puissance nominale	170 W	450 W	575 W
Crête par watt *	26 GFLOP/s/W	184 GFLOP/s/W	182 GFLOP/s/W
Point d'équilibre du modèle roofline *	49 opérations/octet	82 opérations/octet	58 opérations/octet

Quatre lignes portent tout le raisonnement. Les voies de calcul : 32 fois plus sur le GPU, pour une surface de puce de 608 mm² (RTX 4090, 76,3 milliards de transistors) contre environ 260 mm² pour l'ensemble des trois puces du 9950X. La bande passante : onze à vingt fois plus. Le cache : du même ordre, mais servant des objectifs opposés (éviter la mémoire d'un côté, la nourrir en continu de l'autre). Les unités à fonction fixe : présentes d'un côté, absentes de l'autre.

Le modèle roofline : lire les deux plafonds d'un coup

Williams, Waterman et Patterson (2009) ont proposé une façon simple de prédire la performance atteignable par une machine sur un programme donné. Elle repose sur l'intensité arithmétique I du programme, c'est-à-dire le nombre d'opérations qu'il effectue par octet lu ou écrit en mémoire. La performance ne peut dépasser ni la crête de calcul, ni le produit de la bande passante par l'intensité :

performance ≤ min( crête , bande passante × I )

Le point où les deux plafonds se rejoignent, crête ÷ bande passante, est le point d'équilibre de la machine (dernière ligne du tableau 2). Un programme dont l'intensité est inférieure au point d'équilibre est limité par la mémoire ; au-dessus, par le calcul. Les trois puces ont des points d'équilibre comparables, entre 49 et 82 opérations par octet : elles sont toutes trois « équilibrées » de la même façon. Ce qui les distingue, c'est que les deux plafonds du GPU sont onze à vingt-quatre fois plus hauts.

Reprenons l'exemple du chapitre 1 (4K à 120 Hz, hypothèses H1 à H3) : 1,2 TFLOP/s pour 51 Go/s après cache, soit une intensité d'environ 24 opérations par octet, inférieure au point d'équilibre des trois machines. Le rendu est donc, comme la plupart des charges graphiques, limité par la mémoire. Le plafond mémoire du CPU vaut 89,6 × 24 ≈ 2,1 TFLOP/s : le budget de 1,2 TFLOP/s y tiendrait, mais en mobilisant 57 % du bus mémoire, sans marge pour le surdessin réel, la géométrie, les tampons et le système lui-même, et à condition d'un code parfaitement vectorisé. Le plafond mémoire de la RTX 4090 vaut 1 008 × 24 ≈ 24 TFLOP/s, vingt fois le besoin. Le GPU a de la marge pour le surdessin, les ombres, l'anticrénelage et tout ce que les hypothèses H1 à H3 minorent.

Pour aller plus loin : ce que le tableau ne montre pas

La performance sur un seul fil. Un cœur Zen 5 à 5,7 GHz, avec son exécution dans le désordre, termine une chaîne d'instructions dépendantes bien plus vite qu'une voie de GPU à 2,5 GHz qui exécute en ordre. Sur un programme séquentiel, le CPU est la machine la plus rapide des trois, de loin. Le tableau 2 mesure le débit, pas la latence.

La précision. Les cartes graphiques grand public calculent en 64 bits à une fraction de leur débit 32 bits (un seizième à un soixante-quatrième selon les architectures) ; un CPU, à la moitié. Pour du calcul scientifique en double précision, l'écart se resserre fortement en faveur du CPU, ou impose une carte de calcul professionnelle.

Le trajet des données. Une carte graphique est reliée au processeur par un bus PCI Express à seize voies, dont le débit utile est d'environ 63 Go/s dans chaque sens en version 5.0 (RTX 5090) et la moitié en version 4.0 (RTX 4090) : vingt-huit à trente-deux fois moins que la mémoire locale de la carte. Tout ce qui doit faire l'aller-retour entre les deux processeurs à chaque image doit rester petit.

La surface de silicium. Le rapport de surface entre la puce AD102 et le 9950X est d'environ 2,3 pour 1, et le rapport de crête de 19 pour 1 : à surface égale, le GPU offre encore huit fois plus de débit. Ce n'est pas un défaut de conception du CPU ; c'est le prix de la latence.

Le CPU a d'abord tout fait, puis l'industrie a tranché

Trente-six ans d'accélérateurs graphiques, de Doom à l'échec de Larrabee

La séparation entre processeur central et processeur graphique n'a pas toujours existé, et son histoire est le meilleur argument en sa faveur : chaque fois qu'un constructeur a tenté de rendre des images avec des cœurs généralistes, le marché a choisi les unités dédiées. La frise ci-dessous découpe cette histoire en quatre périodes.

Rendu logiciel

Fonctions fixes

Shaders

Shaders unifiés, GPGPU Rayons, IA

1990 1996 2001 2006 20182026

1990 le CPU dessine tout, pixel par pixel
1996 des circuits câblés rasterisent et texturent
2001 les shaders deviennent programmables
2006 unités unifiées, calcul généraliste sur GPU
2018 lancer de rayons et unités matricielles

Les largeurs sont proportionnelles à la durée de chaque période. Les dates charnières sont celles du premier produit grand public de chaque catégorie.

1992 – 1993Wolfenstein 3D puis Doom (id Software) : le rendu est entièrement logiciel, sur un processeur 386 ou 486. Le moteur évite les vrais polygones et réduit le problème à des colonnes de murs verticaux, précisément parce qu'un CPU de l'époque ne peut pas colorier assez de pixels par seconde.
1996Quake rend de vrais triangles texturés en logiciel, au prix d'une optimisation extrême en assembleur ; la même année, la carte Voodoo Graphics de 3dfx confie la rasterisation et le texturage à des circuits câblés. Le gain de fluidité est immédiat et le rendu logiciel disparaît des jeux en quelques années.
1999NVIDIA lance la GeForce 256 et forge le terme « GPU » : la transformation et l'éclairage des sommets (T&L) passent aussi en matériel. Le CPU ne fait plus que décrire la scène.
2001GeForce 3 et DirectX 8 : les étapes de sommet et de pixel deviennent programmables (les shaders). Le pipeline de la figure 1 est né.
2006 – 2007La GeForce 8800 (architecture Tesla, Lindholm et al. 2008) unifie les unités de sommet et de pixel en un seul type de processeur SIMT ; CUDA (2007) l'ouvre au calcul général. Le GPU devient un processeur parallèle généraliste, sans cesser d'être une carte graphique.
2008 – 2009Intel présente Larrabee, une carte graphique faite de cœurs x86 (voir ci-dessous), puis l'abandonne comme produit graphique en décembre 2009.
2012Krizhevsky, Sutskever et Hinton entraînent le réseau de neurones AlexNet sur deux GeForce GTX 580 : la même architecture de débit qui sert au rendu s'avère décisive pour l'apprentissage automatique.
2018Architecture Turing : des unités câblées pour le lancer de rayons et des unités matricielles rejoignent le pipeline.
2022 – 2025GeForce RTX 4090 puis RTX 5090, les deux cartes du tableau 2.

L'expérience cruciale : Larrabee (Intel, 2008–2009)

La meilleure façon de savoir si des cœurs de CPU peuvent remplacer un GPU est d'essayer. Intel l'a fait. Le projet Larrabee, présenté à la conférence SIGGRAPH 2008 (Seiler et al., 2008), assemblait plusieurs dizaines de cœurs x86 en ordre, dérivés du Pentium original, chacun doté d'une unité vectorielle de 16 voies et de quatre fils d'exécution. La rasterisation, le tri des triangles et le mélange étaient réalisés en logiciel. L'article des auteurs eux-mêmes contient deux enseignements précieux :

Pour obtenir un débit compétitif, Intel a dû renoncer aux cœurs dans le désordre : à surface et consommation à peu près égales, un cœur simple en ordre muni d'une large unité vectorielle offrait, selon leur analyse, une crête flottante quarante fois supérieure à celle d'un cœur classique de l'époque. Autrement dit, la première chose à faire pour transformer un CPU en GPU est de lui retirer ce qui fait un CPU.
Même ainsi, l'équipe a conservé des unités de texture câblées, après avoir chiffré la version logicielle à 12 à 40 fois plus lente.

Le produit graphique fut annulé en décembre 2009 ; l'architecture survécut sous le nom de Xeon Phi pour le calcul scientifique, avant d'être abandonnée à la fin de la décennie suivante. Larrabee n'a pas échoué par manque de moyens ni d'ingénieurs : il a échoué parce que, une fois retirées du cœur x86 la latence et la compatibilité qui font sa valeur, il restait un GPU moins bon que ceux de ses concurrents, avec en plus le coût d'un jeu d'instructions conçu pour autre chose.

Pourquoi la séparation s'est imposée partout

Jusqu'au milieu des années 2000, la fréquence des processeurs doublait à peu près tous les deux à trois ans, parce que la réduction des transistors permettait de les cadencer plus vite à puissance constante (règle d'échelle de Dennard, 1974). Vers 2005, les fuites de courant ont mis fin à cette règle : la fréquence a plafonné entre 3 et 5 GHz, où elle se trouve encore. Depuis, la seule source d'accroissement du débit est le parallélisme, et la seule source d'efficacité énergétique est la spécialisation (Hennessy et Patterson, 2019). Le GPU, machine parallèle et spécialisée par construction, était déjà du bon côté de cette transition ; le CPU, machine à latence, a ajouté des cœurs mais ne pouvait pas changer de nature sans cesser de faire son travail. On ne met pas de CPU dans une carte graphique pour la même raison qu'on ne met pas de GPU à la place du CPU : chacun est le meilleur outil pour la moitié du problème que l'autre ne sait pas traiter.

Ce qu'un GPU fait mal, et pourquoi le CPU reste indispensable

Les mêmes lois qui justifient le GPU pour l'image le disqualifient pour le reste

Un argument qui ne vaudrait que dans un sens serait suspect. Si le GPU est la bonne machine pour le rendu, il faut aussi pouvoir dire pourquoi il serait la mauvaise pour le système d'exploitation, le navigateur ou la logique d'un jeu. Trois lois ou mécanismes le montrent.

La loi d'Amdahl : la part séquentielle plafonne tout

Amdahl (1967) a formulé la borne qui gouverne tout calcul parallèle. Si une fraction p d'un programme peut être répartie sur N unités et que le reste, 1 − p, doit s'exécuter en séquence, l'accélération maximale vaut :

S(N) = 1 ÷ [ (1 − p) + p ÷ N ]

Pour un programme parallélisable à 95 % (p = 0,95), seize unités donnent S = 1 ÷ (0,05 + 0,95 ÷ 16) ≈ 9,1, et 16 384 unités ne donnent que S = 1 ÷ (0,05 + 0,95 ÷ 16 384) ≈ 20,0. Les cinq pour cent séquentiels plafonnent l'accélération à vingt quel que soit le nombre de voies. Le rendu d'image a un p extrêmement proche de 1, ce qui rend les 16 384 voies utiles ; la logique d'un jeu ou d'un système a un p bien plus faible, et pour elle la vitesse d'une seule voie, c'est-à-dire la latence, redevient le facteur dominant. C'est le domaine du CPU.

La divergence : le SIMT punit les branchements

Dans un warp, les 32 fils avancent au pas. Si une condition sépare le groupe en deux (par exemple 20 fils prennent la branche « si » et 12 la branche « sinon »), le matériel exécute les deux branches l'une après l'autre en masquant les fils non concernés : le temps est celui de la somme des deux chemins, et le débit utile est divisé d'autant. Dans le pire cas, 32 chemins distincts sont sérialisés et une voie sur 32 travaille. Le code d'un système d'exploitation ou d'un interpréteur, fait de branchements dépendant des données, est exactement ce cas défavorable, là où le prédicteur de branchement d'un CPU excelle.

La latence : ce que le GPU a sacrifié ne revient pas

Une voie de GPU exécute en ordre, à 2,4 GHz, sans prédiction ni spéculation : une chaîne d'instructions dépendantes y progresse plusieurs fois plus lentement que sur un cœur Zen 5 à 5,7 GHz. Lancer un calcul sur la carte coûte en outre quelques microsecondes de mise en route, et tout aller-retour de données passe par le bus PCI Express, trente fois moins rapide que la mémoire graphique. Une tâche courte et urgente (répondre à une frappe au clavier, résoudre une collision, ordonnancer un processus) est perdue d'avance sur GPU.

Le partage du travail dans une machine réelle

C'est pourquoi tout ordinateur, console ou téléphone contient les deux. Dans un jeu, le CPU exécute le système, les pilotes, la logique de la partie, l'intelligence des personnages, la simulation physique, le son et la préparation des commandes de dessin ; le GPU exécute ces commandes. Les processeurs « tout-en-un » des téléphones et des portables (les systems on a chip) et les GPU intégrés des processeurs de bureau ne contredisent pas cette séparation : ils posent un bloc GPU à côté des cœurs de CPU sur la même puce, souvent avec une mémoire commune. Même là, personne n'a jamais remplacé le bloc graphique par des cœurs de CPU supplémentaires, pour toutes les raisons exposées dans cette page.

Questions fréquentes

Un CPU peut-il quand même afficher une scène 3D sans GPU ?

Oui, et il l'a fait jusqu'en 1996 (frise du chapitre 5). Il existe aujourd'hui encore des rasteriseurs entièrement logiciels, utilisés comme solution de repli quand aucun pilote graphique n'est disponible : llvmpipe et Lavapipe dans Mesa, WARP dans Windows, SwiftShader chez Google. Ils implémentent toutes les fonctions du pipeline de la figure 1 sur les unités vectorielles du CPU. Ils suffisent à dessiner un bureau ou une application simple ; sur un jeu contemporain, ils restent un à deux ordres de grandeur en dessous d'une carte graphique d'entrée de gamme, pour les raisons quantifiées aux chapitres 2 à 4 : bus mémoire étroit, lectures dispersées lentes, absence d'unités de texture et de sortie.

Pourquoi les GPU servent-ils aussi à l'intelligence artificielle ?

Parce que l'apprentissage et l'inférence des réseaux de neurones se réduisent à des produits de matrices : des millions d'opérations identiques et indépendantes, avec une intensité arithmétique élevée. C'est le même profil que le rendu, et les mêmes quatre décisions du chapitre 3 s'appliquent (contrôle partagé, tolérance à la latence, bande passante, unités câblées ; les unités matricielles sont l'équivalent pour l'IA de ce que les unités de texture sont pour l'image). La coïncidence a été révélée en 2012 par AlexNet, et elle explique pourquoi les mêmes puces dominent aujourd'hui les deux marchés.

Pourquoi ne pas faire des CPU avec l'architecture des GPU, puisqu'elle est plus efficace ?

Parce que l'efficacité mesurée au chapitre 3 (opérations par joule) n'existe que sur du calcul trivialement parallèle. Sur un programme ordinaire, la loi d'Amdahl et la divergence (chapitre 6) rendent les voies supplémentaires inutiles, et ce qui reste, une voie en ordre à 2,4 GHz sans prédiction, est un processeur médiocre. Intel a tenté le compromis inverse avec Larrabee puis Xeon Phi ; ni l'un ni l'autre n'a trouvé sa place. Les deux architectures sont chacune optimale pour leur moitié du problème, et un compromis entre les deux est en général moins bon que les deux séparément.

Un « cœur CUDA » est-il un cœur ?

Non, au sens où l'on parle d'un cœur de CPU. C'est une voie arithmétique 32 bits, l'équivalent d'une des seize voies d'un registre AVX-512. L'unité qui ressemble le plus à un cœur de CPU dans un GPU est le multiprocesseur (SM chez NVIDIA, unité de calcul chez AMD), qui possède ses ordonnanceurs, ses registres et sa mémoire locale ; il y en a 128 sur une RTX 4090. La note du chapitre 2 détaille la comparaison correcte, en voies de calcul.

Et les GPU intégrés au processeur ?

Ce sont des GPU au sens plein, construits selon les décisions du chapitre 3, mais placés sur la même puce que les cœurs de CPU et partageant leur mémoire. Ils illustrent le rôle de la bande passante : limités au bus DDR du processeur (89,6 Go/s dans l'exemple du tableau 2), ils sont nettement moins performants qu'une carte dédiée, et les constructeurs qui veulent un GPU intégré puissant élargissent le bus mémoire de toute la puce, ce qui rapproche l'ensemble d'une carte graphique dotée de quelques cœurs de CPU plutôt que l'inverse.

Glossaire

ALU: Unité arithmétique et logique (arithmetic logic unit) : le circuit qui effectue une addition, une multiplication ou une comparaison. Dans cette page, « voie de calcul FP32 » désigne une ALU capable d'une multiplication-addition fusionnée sur des nombres flottants 32 bits par cycle.
Amdahl (loi d'): Borne supérieure de l'accélération d'un programme par le parallélisme, fixée par sa fraction séquentielle (chapitre 6).
Bande passante: Quantité de données transportable par un bus en une seconde, en octets par seconde. Grandeur de débit, à distinguer de la latence.
Cache: Petite mémoire rapide placée près des unités de calcul, contenant une copie des données récemment ou prochainement utilisées, pour éviter d'attendre la mémoire principale.
Débit: Nombre d'opérations ou de tâches terminées par unité de temps. Le GPU l'optimise ; le CPU optimise la latence.
Divergence: Situation où les fils d'un même warp prennent des branchements différents ; le matériel sérialise alors les chemins en masquant les fils inactifs.
FMA: Multiplication-addition fusionnée (a × b + c) en une instruction, comptée pour deux opérations flottantes.
Fonction fixe: Circuit câblé pour une opération précise (rasterisation, filtrage de texture, test de profondeur), par opposition à une unité programmable.
Fragment: Candidat à un pixel produit par la rasterisation d'un triangle ; plusieurs fragments peuvent viser le même pixel.
FLOP/s: Opérations en virgule flottante par seconde. Un TFLOP/s vaut 10¹² opérations par seconde. La crête se calcule comme (voies) × (opérations par cycle) × (fréquence).
Intensité arithmétique: Nombre d'opérations effectuées par octet échangé avec la mémoire ; grandeur centrale du modèle roofline (chapitre 4).
Latence: Temps entre le début d'une opération et l'obtention de son résultat. Le CPU l'optimise ; le GPU la tolère.
Little (loi de): Nombre moyen d'éléments dans un système = débit × temps de séjour. Appliquée à la mémoire : requêtes en vol = bande passante × latence (chapitre 2).
Exécution dans le désordre: Technique par laquelle un cœur exécute les instructions dès que leurs opérandes sont disponibles, sans respecter l'ordre du programme, puis rétablit cet ordre pour les résultats.
Pipeline graphique: Suite d'étapes transformant une description géométrique de scène en image (figure 1).
Rasterisation: Étape qui détermine quels pixels de l'écran un triangle projeté couvre, et produit un fragment pour chacun.
Roofline (modèle): Modèle de performance bornée par le minimum de la crête de calcul et du produit de la bande passante par l'intensité arithmétique.
ROP: Unité de sortie (raster operations pipeline) : tests de profondeur et de pochoir, mélange, écriture dans l'image.
Shader: Petit programme exécuté par le GPU une fois par sommet, par fragment ou par élément de calcul.
SIMD: Une instruction, plusieurs données : une même opération appliquée simultanément à plusieurs valeurs (classification de Flynn).
SIMT: Une instruction, plusieurs fils : le SIMD des GPU, où chaque voie est présentée comme un fil d'exécution pouvant diverger.
SM: Multiprocesseur de flux (streaming multiprocessor), bloc de base d'un GPU NVIDIA : ordonnanceurs, registres, unités de calcul et de texture, mémoire locale.
Texel: Élément d'une texture, par analogie avec le pixel de l'écran.
TMU: Unité de texture (texture mapping unit) : adressage, décompression et filtrage des textures, en circuit câblé.
Warp: Groupe de 32 fils d'exécution avançant au pas sur un GPU NVIDIA ; « wavefront » (32 ou 64 fils) chez AMD.

Références

Les caractéristiques des puces proviennent des fiches techniques publiées par les constructeurs (AMD pour le Ryzen 9 9950X, NVIDIA pour les GeForce RTX 4090 et RTX 5090) et des bases de données techniques indépendantes qui les reprennent ; les valeurs marquées d'un astérisque au tableau 2 en sont déduites par les formules données dans le texte. Les publications ci-dessous sont celles citées dans la page.

Amdahl, G. M. (1967). Validity of the single processor approach to achieving large scale computing capabilities. AFIPS Spring Joint Computer Conference, p. 483–485. DOI 10.1145/1465482.1465560.
Flynn, M. J. (1972). Some computer organizations and their effectiveness. IEEE Transactions on Computers, C-21(9), p. 948–960. DOI 10.1109/TC.1972.5009071.
Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), p. 383–387. DOI 10.1287/opre.9.3.383.
Tomasulo, R. M. (1967). An efficient algorithm for exploiting multiple arithmetic units. IBM Journal of Research and Development, 11(1), p. 25–33.
Dennard, R. H. et al. (1974). Design of ion-implanted MOSFET's with very small physical dimensions. IEEE Journal of Solid-State Circuits, 9(5), p. 256–268. DOI 10.1109/JSSC.1974.1050511.
Pineda, J. (1988). A parallel algorithm for polygon rasterization. ACM SIGGRAPH Computer Graphics, 22(4), p. 17–20.
Lindholm, E., Nickolls, J., Oberman, S., Montrym, J. (2008). NVIDIA Tesla: a unified graphics and computing architecture. IEEE Micro, 28(2), p. 39–55. DOI 10.1109/MM.2008.31.
Seiler, L. et al. (2008). Larrabee: a many-core x86 architecture for visual computing. ACM Transactions on Graphics, 27(3), article 18. DOI 10.1145/1360612.1360617. Le chiffre de 12 à 40 pour le filtrage logiciel des textures est également rapporté par Tom's Hardware, « Larrabee: Intel's New GPU », 2009.
Dally, W. J. et al. (2008). Efficient embedded computing. IEEE Computer, 41(7), p. 27–32. DOI 10.1109/MC.2008.224.
Williams, S., Waterman, A., Patterson, D. (2009). Roofline: an insightful visual performance model for multicore architectures. Communications of the ACM, 52(4), p. 65–76. DOI 10.1145/1498765.1498785.
Krizhevsky, A., Sutskever, I., Hinton, G. E. (2012). ImageNet classification with deep convolutional neural networks. Advances in Neural Information Processing Systems 25.
Horowitz, M. (2014). Computing's energy problem (and what we can do about it). IEEE International Solid-State Circuits Conference, p. 10–14. DOI 10.1109/ISSCC.2014.6757323. Les valeurs par opération en 45 nm sont reprises dans Han, S., Mao, H., Dally, W. J. (2016), Deep compression, ICLR.
Hennessy, J. L., Patterson, D. A. (2019). A new golden age for computer architecture. Communications of the ACM, 62(2), p. 48–60. DOI 10.1145/3282307.
NVIDIA. CUDA C++ Programming Guide, section « From graphics processing to general purpose parallel computing », dont la figure 2 de cette page est une adaptation qualitative.
Yee, A. (2024). « Zen5's AVX512 Teardown », numberworld.org ; et Lam, C. (2025). « Zen 5's AVX-512 Frequency Behavior », Chips and Cheese. Mesures indépendantes du débit (deux FMA de 512 bits par cycle) et de la fréquence sous charge AVX-512 des cœurs Zen 5.
Notebookcheck. Fiche de la GeForce RTX 5090 : 170 SM, 21 760 voies, 32 Go GDDR7 sur 512 bits, 1 792 Go/s, 2,41 GHz en pointe.