FuryGpu : processeur graphique FPGA PCIe sur mesure

• Il s’agit d’un processeur graphique sur mesure conçu intégralement du matériel jusqu’aux pilotes pour être utilisé comme un vrai GPU sur un PC moderne
• L’implémentation centrale repose sur un FPGA Xilinx Zynq UltraScale+, intégré sur un PCB personnalisé
• Il se connecte à l’ordinateur hôte en PCIe, ce qui en fait un véritable GPU matériel et non une simple expérimentation logicielle
• Les fonctionnalités prises en charge correspondent au niveau des cartes graphiques haut de gamme du milieu des années 1990, avec pour objectif le rendu des jeux de cette époque
• Il dispose même d’une pile de pilotes Windows moderne, permettant de rendre en temps réel de véritables jeux de cette période à une fréquence d’images supérieure au temps réel

---

Configuration matérielle

• FuryGpu est un GPU entièrement sur mesure conçu dès le départ pour être utilisé sur des ordinateurs modernes
• La logique de traitement graphique est implémentée sur un FPGA Xilinx Zynq UltraScale+
• Il est monté sur un PCB personnalisé et se connecte à l’ordinateur hôte via PCIe

Fonctionnalités graphiques et pilotes

• Les capacités matérielles prises en charge sont équivalentes à celles des cartes graphiques haut de gamme du milieu des années 1990
• Une pile de pilotes logiciels Windows moderne est également fournie, ce qui permet de l’utiliser comme GPU dans un environnement réel

Tâches réalisables

• FuryGpu peut assurer le rendu de véritables jeux de cette époque
• Les performances de rendu peuvent atteindre une fréquence d’images supérieure au temps réel

[GN⁺]

Avis de Hacker News

• Je suis le créateur de ce projet. J’espérais qu’il se diffuse une fois qu’il y aurait un peu plus de contenu sur le site, mais voilà :)
  Pour répondre à la question qu’on me pose le plus souvent : j’ai bien l’intention de publier un jour toute la stack en open source. Cela inclut le schéma/PCB, tout le HDL, le pilote Windows WDDM, le pilote runtime de l’API, et même Quake porté pour utiliser cette API.
  Je dois toutefois régler des questions juridiques liées à mon emploi, et décider de détails comme la licence. Ce n’est pas mon activité principale, mais c’est suffisamment proche pour que je doive être prudent.
  Le premier commit de ce projet date du 22 août 2021, et j’y travaille depuis un peu plus de deux ans et demi. Je n’ai pas écrit d’articles pendant le processus, mais il y a pas mal de vidéos dans la playlist YouTube FuryGpu (https://www.youtube.com/playlist?list=PL4FPA1MeZF440A9CFfMJ7...) qui donnent une idée générale de l’avancement.
  Les prochains billets de blog porteront sur l’interface PCIe et devraient former une série en plusieurs parties, en commençant par le schéma/le layout du PCB, puis la conception FPGA, jusqu’au pilote Windows. Rien que le fait d’avoir écrit l’article sur la Texture Unit m’a donné encore plus de respect pour les personnes qui publient régulièrement ce genre d’articles techniques.
  • J’ai suivi les mises à jour semi-régulières sur Discord, et c’est chouette de voir le projet arriver jusque-là. Ça m’a aussi un peu frustré, parce que mes propres projets FPGA ont beaucoup moins avancé sur la même période, et j’attendais que tout ça soit mis par écrit.
  • En cherchant Xilinx Zynq UltraScale+, ça a l’air assez cher. Beaucoup de gens dépensent des milliers de dollars, voire plus, pour leurs hobbies, donc si on a les moyens ce n’est pas forcément un problème, mais je me demande si c’est le matériel cible final du projet, ou si tu envisages quelque chose au-delà.
  • Je me demande à quel point le projet dépend de blocs hard IP. Est-ce portable vers des FPGA d’autres fournisseurs, comme les Lattice ECP5 ? J’aimerais aussi savoir si le PCIe a été implémenté directement en HDL, ou si tu utilises un bloc IP propriétaire du fournisseur. Ce serait bien aussi d’avoir des statistiques d’utilisation des ressources.
  • Dans l’article sur la Texture Unit, la table ROM pour les offsets d’adresse des niveaux de mip semble prendre pas mal de place. Je me demande si tu as envisagé d’inclure l’adresse de base des mips dans la spécification de texture.
  • Si l’on veut tenter quelque chose de similaire, quels livres recommanderais-tu ? Par exemple, il me faudrait des ressources pour apprendre la conception de cartes PCB pour du matériel PCIe.
• L’impact de la série d’ordinateurs sur breadboard de Ben Eater sur l’électronique amateur est vraiment impressionnant. Moi aussi, ça m’a donné envie de concevoir mon propre CPU « rétro ».
  J’aimerais énormément quelque chose d’aussi facile à enficher et utiliser qu’un 6502, mais avec quelques registres en plus et des fonctions comme la division matérielle ; seulement, c’est vraiment loin d’être trivial.
  Au final, on revient à « autant utiliser un MCU et basta », puis on se heurte au problème de la génération graphique.
  • Ce projet a commencé exactement comme ça. Après avoir construit l’ordinateur 8 bits sur breadboard de Ben Eater, j’ai commencé à chercher ce qu’il faudrait pour fabriquer quelque chose de plus intéressant.
    Comme il est difficile de faire beaucoup de traitements rapides uniquement avec des portes logiques discrètes, je me suis dit qu’apprendre ce qu’on pouvait faire avec un FPGA serait bien plus intéressant.
  • Les registres peuvent être contournés via la pile ou la mémoire, et la division peut être implémentée comme une simple fonction. C’est une partie du plaisir quand on travaille à ce niveau.
    Pour les graphismes, on peut commencer avec une sortie série. C’est une façon de garder le problème abstrait jusqu’à être prêt à s’en occuper. En poussant un Arduino au maximum, on peut en faire une carte graphique VGA très basique [1]. ESP32 to VGA est encore plus simple et fournit aussi clavier et souris [2].
    [1] https://www.instructables.com/Arduino-Basic-PC-With-VGA-Outp...
    [2] https://www.aliexpress.us/item/1005006222846299.html
  • J’allais recommander le Parallax Propeller, surtout le premier modèle disponible en DIP, mais en réalité il est beaucoup plus complexe à programmer et nettement plus puissant. À ce stade, autant regarder du côté de l’ESP32, et on retombe finalement sur « juste utiliser un MCU » :)
    La sortie vidéo est un gros problème à cause de la bande passante requise sur les sorties numériques. Une sortie composite ou VGA peut encore être possible avec des puces faciles à trouver. Le récent Commander X16 a choisi un FPGA pour résoudre ce problème.
  • Je ne vois pas vraiment d’autre exemple aussi populaire. Après une période d’accalmie, il s’est remis récemment à publier des vidéos à peu près régulièrement, avec un public dans les premières centaines de milliers.
    En pratique, j’imagine que moins de 100 000 personnes regardent réellement les vidéos jusqu’au bout, et que celles qui essayent ensuite de faire quelque chose elles-mêmes sont encore moins nombreuses. À l’époque actuelle, l’électronique amateur paraît étonnamment petite.
  • En regardant les graphismes sur MCU, j’ai été déçu de découvrir que le petit GPU NeoChrom intégré aux composants STM32 récents n’est pas entièrement documenté. Historiquement, STM32 avait plutôt tendance à ne pas mettre de boîtes noires dans ses puces ; c’est probablement un bloc IP sous licence d’un tiers.
• Super. Le billet hello aide à comprendre l’intention du créateur : https://www.furygpu.com/blog/hello
  À la lecture, cela semble avant tout être un projet hobby fait pour le plaisir, et il prévoit manifestement d’écrire beaucoup d’articles sur la façon dont il l’a construit.
  Ce qui m’impressionne surtout, c’est que toute la stack fonctionne. Le pilote Windows implémente une API graphique custom, et Quake tourne par-dessus. C’est dommage qu’il n’y ait pas de prise en charge DX/GL, mais on comprend très bien pourquoi il a choisi la voie d’une API custom.
  Je me demande s’il publiera la conception en open source.
  • Ajouter les fonctionnalités nécessaires à une prise en charge D3D de base demanderait un effort considérable, et je suis en train d’évaluer concrètement ce qui serait possible côté performances. Malheureusement, les perspectives ne semblent pas très bonnes.
    Le problème ne se limite pas aux « shaders » : rien que le gestionnaire de fenêtres de l’OS a déjà beaucoup d’exigences pour fonctionner. Les acteurs habituels de ce domaine — AMD, Nvidia, Intel, Imagination, etc. — ont construit tout cela progressivement sur plus de vingt ans d’évolution technologique.
• C’est le projet de mes rêves.

Depuis un an, je travaille sur un GPU centré sur la 2D pour microcontrôleurs avec de fortes contraintes d’E/S (https://github.com/KallDrexx/microgpu). Je l’ai conçu pour permettre de rendre des interfaces utilisateur sur de grands écrans, même avec des périphériques SPI lents, et le travail a été très intéressant
Mais en voyant les limites du pipeline du processeur, je me suis dit qu’avec un FPGA on pourrait aller plus vite. J’ai récemment récupéré quelques FPGA bon marché et commencé à apprendre pour essayer de remplacer le microgpu basé sur ESP32 par une version basée sur FPGA
Avec les enfants et le manque de temps libre, je ne sais pas si j’arriverai à ce niveau, mais j’aimerais en faire ne serait-ce qu’un centième

• Vous le savez probablement déjà, mais pour ceux que cette voie intéresse : pour ce type d’usage, cela vaut clairement la peine de se limiter à des FPGA disposant de transceivers dédiés à haute bande passante
  Même un signal RGB 1080p 60 Hz « basique » exige un traitement de signaux à haute fréquence très difficile à gérer uniquement avec la logique FPGA pure
• Le pipeline a un côté rétro, mais c’est infiniment mieux que rien
  Il existe très peu de GPU open hardware dignes de ce nom. Selon la licence, je n’ai pas trouvé d’informations, et cela pourrait être un premier exemple ainsi qu’un point de départ pour davantage de travaux
  • Il existe aussi ce GPU d’un genre similaire
    https://github.com/asicguy/gplgpu
  • Bien sûr, cela dépend de ce que l’on entend par « open ». À ma connaissance, il n’existe pas de toolchain open source pour les FPGA quelque peu récents ; pour les modifications réelles, on reste donc lié à des outils propriétaires, probablement payants. Si l’on a besoin de plus gros qu’un iCE40 UP5k, il n’y a pratiquement pas d’option
  • Le Ticket2Ride Number9 était un GPU à fonctions fixes de la fin des années 1990, et il a été entièrement publié en open source sous GPL
  • Tout dépend de ce que l’on considère comme un « GPU »
    https://github.com/schlae/graphics-gremlin est un adaptateur compatible MDA/CGA
    https://github.com/OmarMongy/VGA est un cœur VGA
    https://github.com/archlabo/Frix est un SoC complet compatible IBM PC, incluant du VGA
  • Il y a aussi Nyuzi, davantage axé sur les GPU généralistes : https://github.com/jbush001/NyuziProcessor. Cela dit, son créateur a aussi expérimenté l’exécution de graphismes 3D
• J’ai du mal à croire que ce soit ce qu’on a de plus proche d’un petit GPU indépendant. Il n’existe rien comme un GPU au format M.2
  Tout ce que je veux, c’est un GPU M.2 autonome. Les performances peuvent être modestes, du niveau d’un GPU intégré comme Intel UHD Graphics, AMD Radeon ou Qualcomm Adreno
  J’ai une idée de petit produit embarqué qui a besoin de beaucoup de calcul et de réseau, mais de très peu de capacités graphiques. Le NXP Layerscape LX2160A [1] aurait été presque parfait, mais j’ai dû l’écarter faute de GPU intégré. J’ai juste besoin d’un petit GPU
  [1]: https://www.nxp.com/products/processors-and-microcontrollers...
  • Il existe au moins un GPU M.2 fabriqué par Asrock Rack, basé sur le contrôleur Silicon Motion SM750. Des produits au format mPCIe existent aussi dans le même esprit
    Les performances sont très loin de celles des GPU intégrés modernes. Un GPU intégré peut exploiter la mémoire système, le cache et le budget énergétique, alors qu’un simple périphérique M.2 ne le peut pas. Même un GPU PCIe bas de gamme, c’est-à-dire une carte simple slot demi-longueur/demi-hauteur, aura du mal à dépasser un bon GPU intégré, et n’a vraiment de sens que lorsqu’une fonction d’affichage de base est indispensable
  • Et les GPU MXM qu’on trouvait autrefois dans les laptops gaming ? Je sais que le standard est très niche et donc cher. On trouve des 3080M d’occasion autour de 400 dollars sur eBay, mais ça existe, et on peut les convertir en PCIe puis les connecter aussi en M.2
  • La puissance est peut-être trop faible, mais il existe aussi ceci : https://www.matrixorbital.com/ftdi-eve
• Projet vraiment très cool, et c’est agréable de voir davantage de travaux dans ce domaine
  À regarder aussi, il y a le projet Vortex de Georgia Tech [1]. L’approche semble regarder vers l’avenir plutôt que répéter le passé des GPU à fonctions fixes. Le cœur est un ordinateur hautement parallélisé basé sur RISC-V, avec des extensions pour mieux gérer les tâches GPU
  Les cartes d’exécution coûtent plusieurs milliers de dollars, donc ce n’est pas très accueillant pour les amateurs, mais c’est clairement plus accessible qu’un développement propriétaire fermé. La version 2.0 est aussi sortie il y a quelques mois
  [1]: https://vortex.cc.gatech.edu/
• Cela ressemble vraiment à une prouesse impressionnante. J’aimerais voir des photos du matériel réel. Je suis aussi un peu perdu sur le module FPGA utilisé
  Le blog parle d’un Xilinx Kria SoM, mais quand je suis le lien vers les spécifications du module, on dirait qu’il contient un SoC ARM plutôt qu’un FPGA Xilinx. Je ne connais pas bien le monde des FPGA, donc je rate peut-être quelque chose
  https://www.amd.com/en/products/system-on-modules/kria/k26/k...
  • Vous avez de la chance ! https://imgur.com/a/BE0h9cZ

Comme indiqué ailleurs dans ce fil, le Kria SoM combine une matrice FPGA et un cœur ARM matériel chargé du contrôle. Outre le fait qu’il était disponible à l’époque et que la carte de développement Kria était vraiment peu chère, autour de 350 dollars, ces dispositifs incluent des éléments comme une IP DisplayPort matérielle reliée au cœur ARM, ce qui permet de déléguer au firmware des tâches comme la sortie vidéo et l’audio
La version précédente de ce projet tournait sur un Zynq 7020, et il fallait alors écrire soi-même les parties liées au HDMI. Ce n’est pas extrêmement complexe, mais cela consomme pas mal de logique, et cela devient beaucoup plus compliqué si l’on veut le rendre configurable

• Ce n’est pas un choix entre un SoC ARM et un FPGA Xilinx, mais une puce hybride. Elle associe un FPGA et un SoC traditionnel, ce qui évite d’avoir à intégrer un MCU softcore qui consommerait de précieuses ressources FPGA juste pour les tâches de gestion de base
• Xilinx ne divulgue pas la référence exacte du composant FPGA utilisé dans le Kria SoM. Mais d’après les spécifications publiques, cela semble correspondre aux dispositifs ZU3EG-UBVA530-2L et ZU5EV-SFVC784-2L[1], et seul le second dispose de la prise en charge PCIe
  Comme le montre l’article de blog, concevoir une carte FPGA et la bring-up représente déjà une barrière élevée. J’espère qu’un jour les schémas et le code source seront publiés
  [1] https://docs.amd.com/v/u/en-US/zynq-ultrascale-plus-product-...
• Il a été dit que le matériel prend en charge des fonctionnalités équivalentes à celles des cartes graphiques haut de gamme du milieu des années 1990, et comme personne ne semble encore avoir posé la question, je me lance : quel est le niveau de compatibilité VGA ? Par exemple, pourrait-on l’insérer dans n’importe quel PC avec un slot PCIe, démarrer sous DOS et jouer à DOOM ?
• J’aimerais que le créateur détaille l’implémentation de l’interface PCIe. Je n’aurai probablement jamais à faire du matériel à ce niveau, mais je pense qu’il vaut la peine de regarder l’intérieur de PCIe pour sa culture générale
  • Le prochain article de blog doit justement traiter de cela. Ce sera probablement une série en plusieurs parties : le premier article sur le schéma et le layout du PCB, le suivant sur l’interface FPGA et les tests, puis un autre sur le pilote Windows
  • Le FPGA utilisé dispose d’un PCIe natif, donc en général, sur cette partie, on n’obtient qu’une interface vers un bloc IP propriétaire du fournisseur. L’état des interfaces ouvertes dans le monde FPGA est catastrophique. Le mieux que j’aie vu en entièrement open source était à peu près un MAC gigabit
  • J’utilise https://github.com/alexforencich/verilog-pcie au-dessus du cœur IP matériel PCIe de Xilinx. Ce cœur fournit tout ce qui se trouve sous la couche transactionnelle