- Présentation d’une approche exploitant une structure de bandes creuses (sparse strips) pour améliorer l’efficacité du rendu graphique 2D sur CPU
- Recherche centrée sur les structures de données et les méthodes de traitement permettant d’obtenir un rendu haute performance sur CPU plutôt que sur GPU
- La représentation de données creuses réduit l’utilisation mémoire et assure des vitesses de rendu élevées, même dans des scènes complexes
- Une conception qui améliore l’efficacité du traitement parallèle et l’utilisation du cache par rapport aux méthodes classiques de rendu sur CPU
- Une recherche qui montre qu’il est possible de produire des graphismes 2D de haute qualité avec le seul CPU
Aperçu de l’étude
- Cet article vise le rendu 2D haute performance sur CPU et explore des moyens de réduire la dépendance au GPU
- Le concept central est une structure de données appelée bandes creuses (sparse strips), qui stocke efficacement uniquement les portions nécessaires au lieu de conserver des données continues au niveau du pixel
- Cette structure permet de réduire le coût des accès mémoire et d’améliorer la vitesse de rendu
Structure des bandes creuses
- Une bande (strip) représente une plage continue de pixels dans une image 2D, et seule la partie nécessaire est stockée sous une forme creuse (sparse)
- Cette méthode est particulièrement efficace pour les images comportant beaucoup d’espace vide ou les graphismes vectoriels complexes
- Par rapport au rendu classique fondé sur un tampon complet, elle offre une réduction de l’usage mémoire et une meilleure efficacité du cache
Performances et implémentation
- Les instructions SIMD et le multithreading du CPU sont exploités pour maximiser les performances de traitement parallèle
- Les résultats expérimentaux montrent qu’il est possible de traiter la même scène à un niveau de performance proche du rendu en temps réel, même sans GPU
- L’implémentation est basée sur C++ et a été testée sur différentes résolutions et avec divers niveaux de complexité de scène
Possibilités d’application
- Cette approche peut être utilisée dans des environnements centrés sur le CPU, comme le rendu d’interface utilisateur, les moteurs de graphismes vectoriels ou le pipeline 2D des moteurs de jeu
- Elle peut aussi prendre en charge un traitement graphique 2D haute performance dans des systèmes embarqués ou des environnements serveur où le GPU est limité
Conclusion
- L’approche fondée sur les bandes creuses démontre sa capacité à atténuer les goulots d’étranglement du rendu sur CPU et à améliorer l’efficacité mémoire
- Elle met en avant son potentiel comme modèle alternatif aux architectures de traitement graphique dépendantes du GPU
- Pour les chiffres détaillés ou les données comparatives supplémentaires, il faut consulter le contenu du PDF original
1 commentaires
Commentaires sur Hacker News
La structure
struct Stripdéfinie dans l’article semble faire 64 bits (8 octets), mais le texte indique qu’une strip fait 64 octetsEn faisant le calcul, on obtient plutôt 259×8 + 7296 ≈ 9 KB. On dirait qu’il y a une erreur d’unité
C’est peut-être juste une coquille, mais il est aussi possible que chaque strip ait été allouée sur une ligne de cache (64 octets).
Cela permettrait d’éviter le false sharing, donc le moteur de rendu l’a peut-être fait exprès
L’article se concentrait surtout sur les comparaisons de temps d’exécution, pas sur l’espace de stockage
Blaze: Parallel Rasterization on CPU vaut aussi le détour
Le projet est intéressant. D’après la section 3.9, la sortie est au format bitmap, donc il faudra au final copier l’image vers le GPU
Skia migre vers WebGPU, et comme WebGPU prend en charge les compute shaders, la 2D semble devenir un problème globalement résolu en matière de portabilité et de performances
Cela dit, il reste des cas où un moteur de rendu CPU est utile — par exemple sur le Web, où il faut compiler les shaders à l’exécution au chargement de la page
En théorie, on pourrait donc imaginer une architecture qui démarre avec un moteur CPU, comme un JIT JS, puis bascule vers le GPU une fois les shaders prêts
Un autre avantage est la petite taille du binaire. WebGPU (basé sur dawn) est assez volumineux
Lien de référence
Dans un projet plus large, il existe aussi une version appelée Vello Hybrid, qui fait la géométrie sur le CPU et la peinture des pixels sur le GPU
L’idée d’utiliser le moteur CPU pendant la compilation des shaders a aussi été envisagée, mais elle n’a pas encore été implémentée
Au contraire, si l’on rend via le GPU, il faut ensuite recopier l’image, ce qui est inefficace
J’ai récemment écrit du code pour rendre des trajectoires N-body haute précision avec plusieurs millions de sommets,
et je me demande si l’implémentation sur GPU de la représentation RLE proposée dans cet article fonctionnerait bien tout en restant simple
Vidéo de démo
Intéressant. J’aimerais voir les performances sur un seul cœur des moteurs comparés.
Cela donnerait une bonne idée de l’efficacité du code. Les moteurs populaires sont peut-être plus lents, mais utilisent aussi moins de CPU
On peut aussi voir des résultats sur le benchmark officiel de Blend2D ou sur vello_chart, que j’ai réalisé en y ajoutant d’autres moteurs
Est-ce que l’un des directeurs de thèse, Raph Levien, est bien l’auteur de l’ancienne bibliothèque Libart ?
C’est un peu hors sujet, mais je me demande depuis quand l’aperçu PDF de GitHub s’est mis à ne charger que certaines pages
Je trouve qu’il vaudrait mieux, comme avant, charger le PDF complet d’un coup et laisser le navigateur le rendre
Je me demande s’il existe des benchmarks permettant de vérifier la correctness du moteur de rendu
Le principe est de mesurer la radiosité d’une scène réelle et de la comparer aux résultats de la simulation
En rendu temps réel, on compare aussi parfois avec des moteurs de rendu hors ligne comme Arnold ou Octane comme référence
Wiki Cornell box
Il n’existe pas de moteur de rendu qui reproduise parfaitement la réalité, tous acceptent un certain niveau de compromis