Pour comprendre la différence, il faut séparer plusieurs niveaux que le mot scheduler mélange facilement. Il y a d'abord la réception des commandes envoyées par le pilote, ensuite l'affectation des groupes de travail aux unités de calcul, puis la sélection cycle par cycle d'une wave ou d'un warp capable d'utiliser les unités d'exécution.

AMD et NVIDIA effectuent ces trois opérations avec du matériel dédié. Aucun des deux GPU n'attend que le CPU choisisse à chaque instant quel groupe de shaders doit exécuter la prochaine instruction.

Chez AMD, le travail descend par Command Processor, ACE puis SPI

Sur l'architecture RDNA utilisée par les Radeon, le Command Processor se trouve en amont du pipeline. Il récupère et décode les commandes soumises au GPU. Pour les tâches de calcul, les lancements peuvent ensuite être pris en charge par les Asynchronous Compute Engines, ou ACE.

Les ACE permettent notamment de gérer plusieurs files de travail et de faire progresser des kernels de manière asynchrone. Le travail est découpé en workgroups avant d'arriver au Shader Processor Input, souvent désigné SPI.

C'est à ce niveau qu'une grande partie de la planification spatiale devient visible. Le SPI regarde quelles Compute Units disposent des ressources nécessaires et leur attribue les workgroups.

AMD documente quatre ressources particulièrement importantes pour cette décision : les emplacements disponibles pour les wavefronts, les registres vectoriels VGPR, les registres scalaires SGPR et la mémoire locale LDS. Une CU qui possède encore des unités arithmétiques libres peut donc malgré tout être incapable d'accueillir un nouveau workgroup si celui-ci exige trop de registres ou de mémoire locale.

Une fois dans la CU, on ne planifie plus un workgroup mais des waves

RDNA 4 utilise principalement des wavefronts de 32 threads pour le code graphique moderne, même si l'architecture conserve aussi un mode Wave64. La documentation ROCm actuelle répertorie d'ailleurs les RX 9070, RX 9070 XT et RX 9060 XT avec une taille de wave supportée de 32 ou 64.

Le scheduler local de la Compute Unit arbitre alors entre les wavefronts résidentes. Si une wave attend une donnée venant de la mémoire, une autre qui possède déjà ses opérandes peut avancer.

C'est le principe fondamental qui permet à un GPU de masquer la latence sans effectuer un changement de contexte lourd comparable à celui d'un système d'exploitation. Plusieurs waves résident simultanément dans l'unité, et le matériel choisit du travail exécutable parmi elles.

Blackwell arrive au même problème par les Streaming Multiprocessors

NVIDIA utilise un vocabulaire différent. Le groupe de travail CUDA ou DirectX correspond grossièrement au thread block, l'équivalent fonctionnel du workgroup AMD, tandis qu'un groupe SIMD de 32 threads est appelé warp.

Une fois les thread blocks distribués aux Streaming Multiprocessors, ou SM, la planification devient très locale.

Un SM Blackwell GeForce est divisé en quatre partitions de traitement. Chacune possède son propre warp scheduler, son fichier de registres et son cache d'instructions L0. Cela donne quatre warp schedulers par SM.

Chaque scheduler travaille sur les warps dont sa partition a la charge et choisit ceux qui sont prêts à envoyer une instruction vers les pipelines disponibles. Là encore, l'objectif est de garder les unités occupées pendant que d'autres warps sont bloqués sur une dépendance ou un accès mémoire.

32 threads des deux côtés ne veut pas dire organisation identique

Un warp NVIDIA contient 32 threads. Une Wave32 Radeon en contient également 32. Cette similitude facilite parfois les comparaisons, mais elle ne rend pas les deux machines équivalentes.

Chez AMD, la terminologie architecturale conserve les Compute Units, regroupées dans l'organisation RDNA autour des Workgroup Processors et des Shader Engines. Le SPI effectue l'affectation des workgroups en tenant compte des ressources de chaque CU.

Chez NVIDIA, le SM est l'unité centrale de résidence des thread blocks et rassemble quatre partitions possédant leurs schedulers de warps.

Le compilateur, la taille du groupe de threads, la consommation de registres et de mémoire partagée déterminent donc l'occupation de manière différente, même lorsque le shader fait exactement le même calcul.

La plus grosse différence pratique apparaît avec l'occupation

Un scheduler n'invente pas du parallélisme. Pour masquer une attente mémoire, il faut déjà qu'une autre wave ou un autre warp prêt à travailler réside sur l'unité.

Sur AMD, augmenter trop fortement le nombre de VGPR utilisés par une wave peut réduire le nombre de waves qu'une CU peut conserver simultanément. Une forte consommation de LDS peut produire le même effet au niveau d'un workgroup.

Sur Blackwell, le nombre de registres, la shared memory par block et le nombre de warps limitent de la même manière l'occupation des SM. Pour les GeForce Blackwell en compute capability 12.0, NVIDIA documente notamment jusqu'à 48 warps concurrents par SM, un fichier de 64K registres 32 bits et jusqu'à 32 thread blocks résidents, sous réserve que les autres ressources le permettent.

Il est donc possible d'avoir énormément d'ALU théoriquement disponibles et de les nourrir médiocrement simplement parce qu'un shader consomme assez de registres pour diminuer fortement le nombre de groupes résidents.

NVIDIA ajoute aussi des mécanismes destinés aux workloads très persistants

Blackwell dispose de fonctions qui dépassent le simple warp scheduler historique. NVIDIA documente notamment les Thread Block Clusters ainsi que Cluster Launch Control sur certaines implémentations Blackwell.

L'idée devient particulièrement intéressante pour les kernels persistants : au lieu de terminer une grille de travail strictement selon une affectation décidée au lancement, un groupe déjà résident peut demander dynamiquement un nouveau morceau de travail. Les bibliothèques CUDA comme CUTLASS utilisent ce mécanisme pour des tile schedulers spécialisés sur Blackwell.

Toutes les fonctions de Blackwell datacenter ne sont cependant pas présentes à l'identique sur les GeForce. La documentation CUDA distingue notamment les capacités 10.0 et 12.0, et certaines fonctions disponibles sur les puces Blackwell destinées au calcul professionnel ne doivent pas être automatiquement attribuées à une RTX 5090 ou une RTX 5080.

RDNA 4 ne bouleverse pas ce niveau de la machine autant que le ray tracing ou l'IA

AMD a fortement communiqué sur les nouvelles unités de ray tracing, les accélérateurs IA et le support des opérations matricielles de RDNA 4. Le schéma général de distribution des workloads reste néanmoins reconnaissable par rapport aux générations RDNA précédentes : commandes, ACE, SPI, CU et scheduling des waves.

La documentation ISA de RDNA 4 confirme par ailleurs le maintien des modes Wave32 et Wave64. Le Wave32 reste le format naturel des charges graphiques Radeon modernes, tandis que certaines instructions matricielles peuvent fonctionner dans les deux modes.

Le pilote reste important, même avec beaucoup de matériel dédié

« Hardware scheduler » ne signifie pas que le pilote disparaît. Le pilote construit les files de commandes, gère les dépendances, configure le contexte, compile ou fournit le code shader et décide d'une grande partie de la stratégie avant que le GPU commence son travail.

Le matériel prend ensuite en charge la distribution à une granularité beaucoup plus fine et à une fréquence impossible à gérer efficacement depuis le CPU.

C'est aussi pourquoi Windows Hardware-Accelerated GPU Scheduling, souvent abrégé HAGS, ne doit pas être confondu avec les warp schedulers ou wavefront schedulers internes aux GPU. HAGS concerne la gestion de files et de contextes entre Windows, le pilote et le GPU. Les schedulers RDNA ou Blackwell dont il est question ici travaillent plusieurs étages plus bas, à l'intérieur même de la puce.

AMD centralise davantage l'affectation des workgroups, NVIDIA expose davantage la planification par SM

La comparaison la plus utile tient finalement en deux étages.

RDNA 4 possède une hiérarchie où le Command Processor et les ACE alimentent le SPI, lequel surveille les ressources et place les workgroups sur les CU. Les schedulers locaux arbitrent ensuite entre les waves résidentes.

Blackwell distribue les blocks vers les SM, puis quatre warp schedulers par SM sélectionnent en permanence les warps prêts à exécuter dans leurs partitions respectives.

Dans les deux cas, l'objectif reste identique : garder des milliers de threads disponibles, exploiter ceux qui peuvent avancer immédiatement et masquer les temps morts des autres. Les noms changent davantage que le problème à résoudre.