Malgré les avancées, les GPU modernes ont toujours des rasteriseurs fixes. Hautement personnalisable, avec des shaders programmables mais néanmoins pas entièrement programmables.

Pourquoi donc?

Pourquoi les GPU ne peuvent-ils pas être simplement des appareils massivement parallèles avec des unités informatiques universelles où le rasterizer n'est qu'un logiciel pour cet appareil fourni par l'utilisateur?

Le fait d'avoir du matériel à fonction fixe est-il si avantageux en termes de performances qu'une telle approche est irréalisable?

En bref, les raisons de performances expliquent pourquoi elles ne sont pas programmables.

Histoire et marché

Dans le passé, il existait des cœurs séparés pour les processeurs de vertex et de fragments afin d'éviter les conceptions de FPU gonflées. Il y avait certaines opérations mathématiques que vous ne pouviez faire que dans le code du shader de fragments par exemple (car elles n'étaient principalement pertinentes que pour les shaders de fragments). Cela produirait de graves goulots d'étranglement matériels pour les applications qui ne maximisaient pas le potentiel de chaque type de cœur.

Comme les shaders programmables sont devenus plus populaires, des unités universelles ont été introduites. De plus en plus d'étapes du pipeline graphique ont été implémentées dans le matériel pour faciliter la mise à l'échelle. Pendant ce temps, GPGPU est également devenu plus populaire, les fournisseurs ont donc dû intégrer certaines de ces fonctionnalités. Il est néanmoins important de noter que la majorité des revenus des GPU étaient encore des jeux vidéo, donc cela ne pouvait pas interférer avec les performances.

Finalement, un grand acteur, Intel, a décidé d'investir dans des rasteriseurs programmables avec leur architecture Larrabee . Ce projet était censé être révolutionnaire, mais les performances étaient apparemment inférieures à ce qui était souhaité . Il a été fermé et certaines parties ont été récupérées pour les processeurs Xeon Phi. Il convient de noter cependant que les autres fournisseurs n'ont pas mis en œuvre cela.

Tentatives de rastérisation logicielle

Il y a eu quelques tentatives de pixellisation via un logiciel, mais elles semblent toutes avoir des problèmes de performances.

Un effort notable a été une tentative de Nvidia en 2011 dans ce document . Cela a été publié près de la fin de Larrabee, il est donc très possible que ce soit une réponse à cela. Quoi qu'il en soit, il y a des chiffres de performances dans ce domaine, et la plupart d'entre eux affichent des performances plusieurs fois plus lentes que les rastérisateurs matériels.

Problèmes techniques liés à la rastérisation logicielle

De nombreux problèmes ont été rencontrés dans le document Nvidia. Voici cependant quelques-uns des problèmes les plus importants avec les rastériseurs logiciels:

Problèmes majeurs

• Interpolation: l'implémentation matérielle génère des équations d'interpolation dans du matériel spécialisé. C'est lent pour le logiciel de rendu car cela devait être fait dans le fragment shader.

• Anticrénelage: il y avait également des problèmes de performances avec l'anticrénelage (en particulier avec la mémoire). Les informations concernant les échantillons de sous-pixels doivent être stockées sur la mémoire de la puce, ce qui n'est pas suffisant pour contenir cela. Julien Guertault a souligné que le cache de texture / cache peut être plus lent avec le logiciel. MSAA a certainement des problèmes ici car il déborde le cache (les caches non texturés) et va en mémoire hors de la puce. Les trameurs compressent les données stockées dans cette mémoire, ce qui contribue également aux performances ici.

• Consommation d'énergie: Simon F a souligné que la consommation d'énergie serait inférieure. Le document mentionne que les ALU personnalisées sont dans les rastérisateurs (ce qui réduirait la consommation d'énergie), et cela aurait du sens puisque les unités de traitement des fragments et des sommets avaient auparavant des ensembles d'instructions personnalisés (donc probablement des ALU personnalisées également). Ce serait certainement un goulot d'étranglement dans de nombreux systèmes (par exemple, mobiles), bien que cela ait des implications au-delà des performances.

Sommaire

TL; DR: il y a trop d'inefficacités que le rendu logiciel ne peut pas dépasser, et ces choses s'additionnent. Il existe également de nombreuses limitations plus importantes, en particulier lorsque vous traitez avec la bande passante VRAM, les problèmes de synchronisation et les calculs supplémentaires.