GPU open source sur RISC-V

Un groupe de passionnés propose un nouvel ensemble d'instructions graphiques conçues pour les graphiques 3D et le traitement multimédia. Ces nouvelles instructions sont construites sur le jeu d'instructions vectorielles de base RISC-V. Ils ajouteront la prise en charge de nouveaux types de données spécifiques aux graphiques en tant qu'extensions en couches dans l'esprit de l'architecture de jeu d'instructions RISC-V (ISA). Les vecteurs, les mathématiques transcendantales, les pixels et les textures et les opérations de tampon Z/Frame sont pris en charge. Il peut s'agir d'un ISA CPU-GPU fusionné. Le groupe l'appelle le RV64X car les instructions seront longues de 64 bits (32 bits ne seront pas suffisants pour prendre en charge un ISA robuste).

Pourquoi maintenant ?

Le monde a beaucoup de GPU parmi lesquels choisir, pourquoi cela ? Car, selon le groupe, les GPU commerciaux sont moins efficaces pour répondre à des besoins inhabituels tels que l'écrêtage de tronc de cône 3D biphasé, le HPC adaptable (FFT à profondeur de bits arbitraire), le SLAM matériel. Ils pensent que la collaboration fournit des normes flexibles, réduit l'effort de 10 à 20 années-homme autrement nécessaire et aidera à la vérification croisée pour éviter les erreurs.

L'équipe affirme que leur motivation et leurs objectifs sont motivés par le désir de créer une conception de petite taille et efficace pour la zone avec une programmabilité et une extensibilité personnalisées. Il devrait offrir une propriété et un développement de propriété intellectuelle à faible coût et ne pas concurrencer les offres commerciales. Il peut être implémenté dans des cibles FPGA et ASIC et sera libre et open source. La conception initiale sera ciblée sur des microcontrôleurs à faible consommation. Il sera conforme à Khronos Vulkan et prendra en charge au fil du temps d'autres API (OpenGL, DirectX et autres).

Le matériel final sera un cœur RISC-V avec une unité fonctionnelle GPU. Pour le programmeur, cela ressemblera à une seule pièce de matériel avec des instructions longues de 64 bits codées en tant qu'instructions scalaires. Le modèle de programmation est un SIMD apparent, c'est-à-dire que le compilateur génère un SIMD à partir d'opcodes scalaires préfixés. Il inclura le backend SIMD à problème variable, le front-end vectoriel, les exceptions précises, l'ombrage des branches et beaucoup Suite. Il n'y aura pas besoin d'un mécanisme d'appel RPC/IPC pour envoyer des appels d'API 3D vers/depuis l'espace mémoire CPU inutilisé vers l'espace mémoire GPU et vice-versa, explique l'équipe. Et il sera disponible en virgule fixe 16 bits (idéal pour les FPGA), ainsi qu'en virgule flottante 32 bits (ASIC ou FPGA).

La conception utilisera le format Vblock (issu de l'effort Libre GPU) :

• C'est un peu comme VLIW (seulement pas vraiment)
• Un bloc d'instructions est préfixé avec des balises de registre qui donnent un contexte supplémentaire aux instructions scalaires dans le bloc
• Les sous-blocs incluent :la longueur du vecteur, le swizzling, les remplacements de vecteur/largeur et la prédication.
• Tout cela est ajouté aux opcodes scalaires
• Il n'y a pas d'opcodes vectoriels (et pas besoin d'en)
• Dans le contexte vectoriel, cela se passe comme ceci :si un registre est utilisé par un opcode scalaire et que le registre est répertorié dans le contexte vectoriel, le mode vectoriel est activé
• L'activation entraîne une boucle for au niveau matériel émettant plusieurs opérations scalaires contiguës (au lieu d'une seule).
• Les implémenteurs sont libres d'implémenter la boucle de la manière qu'ils souhaitent :SIMD, à plusieurs problèmes, à exécution unique.

La conception utilisera des scalaires (8, 16, 24 et 32 ​​bits fixes et flottants), ainsi que des transcendants (sincos, atan, pow, exp, log, rcp, rsq, sqrt, etc.). Les vecteurs (RV32-V) prendront en charge les opérations vectorielles de 2 à 4 éléments (8, 16 ou 32 bits/élément), ainsi que des instructions spécialisées pour un pipeline de rendu graphique 3D général pour les points, les pixels, les texels (essentiellement des vecteurs spéciaux )

• Points XYZW (fixes et flottants 64 et 128 bits)
• Pixels RGBA (8, 16, 24 et 32 ​​bits)
• Texels UVW (8, 16 bits par composant)
• Lumières et matériaux (Ia, ka, Id, kd, Is, ks…)

Les matrices seront des matrices 2 × 2, 3 × 3 et 4 × 4 seront prises en charge en tant que type de données natif avec des structures de mémoire pour les prendre en charge pour les vecteurs d'attributs et seront essentiellement représentées dans une matrice 4 × 4.

Parmi les avantages de la fusion CPU-GPU ISA, citons la possibilité d'implémenter un pipeline graphique standard en microcode, de prendre en charge les shaders personnalisés et d'implémenter des extensions de lancer de rayons. Il prend également en charge les vecteurs pour les simulations numériques avec des types de données entiers 8 bits pour l'IA et l'apprentissage automatique.

Des rastériseurs personnalisés peuvent être implémentés, tels que des splines, des surfaces SubDiv et des patchs.

La conception sera suffisamment flexible pour pouvoir implémenter des étapes de pipeline personnalisées, des étapes de tampon de géométrie/pixel/image personnalisées, des tesselators personnalisés et des opérations d'instanciation personnalisées.

Schéma fonctionnel RV64X

L'implémentation de référence RV64X comprendra :

• Cache SRAM d'instructions/données (32 Ko)
• Microcode SRAM (8 Ko)
• Décodeur d'instructions à double fonction
  • Implémentation câblée RV32V et X
  • Décodeur d'instructions micro-codées pour ISA personnalisé
• Quad Vector ALU (32 bits/ALU—fixe/flottant)
• Fichiers de registre 136 bits (1 K éléments)
• Unité de fonction spéciale
• Unité de texture
• Tampon de trame local configurable

La conception est censée être évolutive comme indiqué ci-dessous.

Conception évolutive du RV64X

La conception RV64X a plusieurs idées novatrices, notamment l'ISA CPU-GPU unifiée fusionnée, des registres configurables pour les types de données personnalisés et un micro-code basé sur SRAM défini par l'utilisateur pour les extensions matérielles personnalisées définies par l'application pour :

• Étapes de rastérisation personnalisées
• Traçage de rayons
• Apprentissage automatique
• Vision par ordinateur

La même conception sert à la fois de microcontrôleur graphique autonome ou d'unité de shader évolutive, et les formats de données prennent en charge les implémentations FPGA natives ou ASIC.

Pourquoi les graphiques ouverts sont-ils nécessaires ?

Les développeurs pensent que la plupart des processeurs graphiques couvrent le haut de gamme comme les jeux, le trading haute fréquence, la vision par ordinateur et l'apprentissage automatique. Ils pensent que l'écosystème manque d'un noyau graphique évolutif pour des applications plus courantes pour des choses comme les kiosques, les panneaux d'affichage, les jeux de casino, les jouets, la robotique, les appareils électroménagers, les appareils portables, les interfaces homme-machine industrielles, l'infodivertissement et les groupes de jauges automobiles. Pendant ce temps, des langages de programmation spécialisés doivent être utilisés pour programmer les cœurs GPU pour OpenGL, OpenCL, CUDA, DirectCompute et DirectX.

Une extension graphique pour RISC-V résoudrait l'évolutivité et les charges multilingues permettant un niveau plus élevé d'innovation de cas d'utilisation.

Prochaines étapes

Il s'agit d'une spécification très précoce, encore en développement et sujette à changement en fonction des commentaires des parties prenantes et de l'industrie. L'équipe mettra en place un forum de discussion. Un objectif immédiat est de créer un exemple d'implémentation avec un simulateur de jeu d'instructions, une implémentation FPGA utilisant une IP open source et une IP personnalisée conçue comme un projet open source. Des démos et des benchmarks sont en cours de conception. Les développeurs intéressés à participer doivent contracter Atif Zafar.

Quant au GPU Libre-RISC 3D, l'objectif de l'organisation est de concevoir un CPU, un VPU et un GPU hybrides. Il ne s'agit pas, comme cela est largement rapporté, d'un « GPU exclusif dédié ». L'option existe pour créer un produit GPU autonome. Leur objectif principal est de concevoir un processeur SoC tout-en-un complet qui inclut un VPU et un GPU sous licence Libre.

Qu'en pensons-nous ?

La population de fournisseurs de GPU augmente. Nous en avons maintenant plus d'une douzaine.

AppleLibre-RISC-V 3D GPUQualcommAMDNvidiaRISC-V GraphicsArmIntelThink-SiliconDMPJingjia MicroVeriSilcionImagination Technologies

Une application non répertoriée comme utilisateur potentiel d'un petit GPU gratuit et flexible comprend la crypto-monnaie et l'exploitation minière.

Si l'objectif de la communauté RISC-V est d'émuler les fournisseurs IP tels que Arm et Imagination, alors nous pouvons nous attendre à voir des conceptions DSP, ISP et DP. Il existe au moins une proposition Open DSP ; peut-être qu'il peut être intégré à la communauté RISC-V.

Il faudra au moins deux ans avant que des implémentations matérielles n'apparaissent. L'un des candidats les plus logiques pour adopter cette conception est Xilinx, qui utilise maintenant Arm's Mali dans sa conception Zynq. Nous nous attendrions également à voir plusieurs implémentations sortir de Chine.

>> Cet article a été initialement publié le notre site partenaire, EE Times.

---

Jon Peddie , un pionnier de l'industrie graphique, est président de Jon Peddie Research.

---

Pour plus d'informations sur Embedded, abonnez-vous à la newsletter hebdomadaire d'Embedded.