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?

gpu rasterizer

— mrpyo
source

"Pourquoi une unité de traitement graphique n'est-elle pas à l'unité de traitement universelle", est-ce que vous vous interrogez?

— Andreas

@Andreas Non, ma question est telle qu'elle est indiquée dans le message. Pourquoi les rastérisateurs sont-ils toujours une partie matérielle, alors qu'ils pourraient être effectués dans le logiciel (en fait, ils pourraient déjà l'être avec OpenCL ou des shaders de calcul). La question est pourquoi ce n'est pas commun ... peut-être que c'est simplement une performance, je ne sais pas, c'est pourquoi je demande ...

— mrpyo

Vous pouvez contourner la pixellisation et implémenter votre propre tramage avec des unités de calcul sur des GPU modernes et je connais en fait des gens qui le font à des fins spécifiques.

— JarkkoL

Les trameurs convertissent les polys vectoriels en un tas de pixels que nous pouvons éclairer. Lorsque nous n'aurons plus de pixels ou que nous cesserons d'utiliser la géométrie vectorielle, nous n'aurons plus besoin de trameurs. Peu importe à quoi ressemble le reste de votre pipeline, à la fin de la journée (ou du cadre), vous avez besoin de pixels. Le rasterizer nous dit simplement quels pixels nous préoccupent pour un triangle donné. Tout cela est programmable - si vous voulez une sortie différente du rasterizer, envoyez différents triangles à sa manière. Ou dessinez simplement tout sur une texture de rendu dans un shader de calcul et blit à l'écran avec un quadrilatère aligné sur la vue.

— 3Dave

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.

— as
source

Je ne pense pas que vous ayez besoin de stocker les échantillons de sous-pixels si le filtrage de boîte est suffisant, alors vous pouvez simplement faire des moyennes courantes.

— joojaa

Je soupçonne que l'échantillonnage de texture et le cache sont probablement également des domaines où les implémentations matérielles permettent des performances autrement impossibles à obtenir avec les implémentations logicielles.

— Julien Guertault

@aces Un autre élément qui mérite d'être mentionné est le pouvoir. Le matériel dédié fera le même travail, généralement avec une fraction du budget de puissance et, avec la limitation de puissance déjà un problème, en particulier sur les appareils mobiles, le fait de devenir entièrement programmable le rendrait bien pire.

— Simon F

@JulienGuertault Fair point, mais je pense que cela s'applique principalement à MSAA. Les résultats des tests semblent indiquer que ce n'est pas un problème énorme lorsque tout tient sur la mémoire sur puce (bien que cela puisse avoir un impact sur les performances).

— As

@SimonF Je pense que c'est aussi un excellent point. Je l'ai inclus dans la réponse.