Par où commencer lorsque vous envisagez de créer un GPU?

J'ai vu cette vidéo l'autre jour et cela m'a fait réfléchir sur la façon de procéder et de concevoir quelque chose comme le GPU. Par où commenceriez-vous? Je suis plus intéressé par la lecture de leur fonctionnement et non par la création d'un TTL (de toute façon).

Je sais que cela ressemble à une question «comment faites-vous un langage de programmation» mais tous les points de départ seraient bons car je ne sais pas par où commencer.

C'est un peu comme aller à votre examen final de collage pour un cours de science et avoir ceci comme question: Décrivez l'univers. Soyez bref, mais concis. Il n'y a aucun moyen de répondre à cette question d'une manière pratique - je vais donc répondre à une autre question.

Quels sont les types de choses que je dois savoir avant d'essayer de concevoir un GPU?

Dans un ordre chronologique approximatif, ils sont:

1. Soit VHDL ou Verilog.
2. FPGA (zone utile pour jouer avec l'écriture de la logique numérique).
3. Des trucs de chemin de données de base, comme les FIFO.
4. Interfaces de bus, comme l'interfaçage PCIe et DDR2 / 3
5. Implémentations binaires de fonctions mathématiques, y compris virgule flottante, etc.
6. Conception du processeur.
7. Normes d'interfaçage vidéo.
8. Trucs analogiques haute vitesse (le côté analogique du numérique haute vitesse)
9. PLL et autres trucs d'horloge semi-avancés.
10. Conception de circuits imprimés de circuits à grande vitesse.
11. Conception de convertisseur DC / DC basse tension et courant élevé.
12. Beaucoup, beaucoup de logiciels.
13. Et enfin, ASIC ou autre conception de type de puce personnalisée.

J'oserai également dire que vous ne ferez pas ce genre de choses avec des puces logiques TTL. Je doute que vous puissiez obtenir une interface mémoire DDR2 / 3 raisonnable fonctionnant avec des puces TTL normales. L'utilisation d'un grand FPGA serait beaucoup plus facile (mais pas facile).

Passer à l'étape 6 sera probablement "assez bon pour étancher votre soif intellectuelle". Cela pourrait également être fait dans un délai raisonnable - environ un an - pour se fixer un objectif à court terme.

EDIT: Si tout ce que vous voulez faire est de cracher un signal vidéo, c'est relativement facile. C'est, en substance, un morceau de mémoire qui est déplacé vers un affichage à 60 Hz. Le diable est dans les détails, mais voici un aperçu de la façon de procéder:

Commencez avec une RAM double port. Il n'est pas nécessaire qu'il s'agisse d'un véritable ram à deux ports, juste de la RAM qu'un processeur peut lire / écrire et que votre circuit vidéo peut lire. La taille et la vitesse de cette RAM dépendront du type d'écran que vous conduisez. Personnellement, j'utiliserais la SDRAM DDR2 connectée à l'interface mémoire d'un FPGA Xilinx Spartan-6. Leur noyau «générateur d'interface mémoire» (MIG) facilite la transformation en RAM à double port.

Ensuite, concevez un circuit qui contrôlera la lecture de cette RAM et crachera ces données sur un simple bus. Normalement, vous lisez simplement la RAM séquentiellement. Le "bus simple" n'est vraiment que cela. Ce sont des bits avec la valeur en pixels dessus - et c'est tout. Ce circuit devra faire deux autres choses: il devra retourner au début de la RAM à chaque image vidéo et il devra "mettre en pause" la sortie pendant les périodes de retracement horizontal / vertical.

Troisièmement: créez un circuit qui émettra les signaux de contrôle vidéo (HSync, Vsync, etc.) ainsi que dire au circuit précédent quand faire une pause et redémarrer. Ces circuits sont en fait assez faciles à faire. Il est plus difficile de trouver la norme vidéo appropriée, à mon humble avis.

Et enfin: connectez les signaux de contrôle et le bus de données de pixels vidéo à «quelque chose». Cela pourrait être un petit écran LCD couleur. Il pourrait s'agir d'un DAC vidéo pour la sortie d'un signal compatible VGA. Il existe des encodeurs NTSC / PAL qui accepteraient ces signaux. Etc.

Si la résolution est vraiment petite, vous pourriez vous en sortir en utilisant la RAM interne du FPGA au lieu d'une SDRAM DDR2 externe. Je dois vous avertir que si la SDRAM DDR2 est utilisée, vous aurez probablement besoin d'un FIFO et d'autres choses, mais ce n'est pas non plus très difficile. Mais avec la SDRAM DDR2, vous pouvez prendre en charge des écrans de résolution assez élevée. Vous pouvez également trouver des cartes de développement FPGA avec DAC VGA intégré et d'autres formes de sorties vidéo.

Racing the Beam est un aperçu détaillé de la conception et du fonctionnement de l'Atari VCS. Il a un traitement complet de l' adaptateur d'interface de télévision.

Le TIA concerne le GPU le plus simple et le plus pratique.

Comprendre un système de travail petit mais complet peut être un bon moyen d'apprendre un nouveau sujet.

Des schémas complets sont disponibles, ainsi qu'un manuel technique .

Si vous voulez simplement mettre des trucs à l'écran et pensez que vous pourriez vraiment, vraiment apprécier le câblage, vous pouvez viser un système graphique de caractères au début des années 1980. Si vous pouvez atteindre le timing du RS-170A, vous pourriez même être en mesure de pousser le signal dans une entrée AV de rechange sur un téléviseur plasma de 50 pouces, et de faire du rétro de façon spectaculaire.

Certains des premiers systèmes utilisaient leurs processeurs 8 bits pour générer directement l'affichage, par exemple le 6507 dans l'Atari 2600 et le Z-80 dans le Timex Sinclair ZX-81. Vous pouvez même faire la même chose avec des microcontrôleurs modernes. L'avantage de cette façon est que le matériel est simple, mais le logiciel doit généralement être en assembleur, et est très exigeant, et les résultats seront vraiment décevants. On peut dire que le 2600 employait du matériel supplémentaire, mais le TIA n'avait pas beaucoup de FIFO, et le 6502 (enfin, 6507, vraiment) devait lui envoyer des octets en temps réel. Dans cette approche, il n'y a pas de mode vidéo standard; chaque application qui utilise la vidéo doit être intimement combinée avec les besoins de maintien de la fluidité des pixels.

Si vous voulez vraiment construire quelque chose à partir de TTL, le prochain niveau de complexité serait d'opter pour l'affichage de texte basé sur la ROM de caractères. Cela vous permet de mettre, disons, 256 caractères dans n'importe laquelle, par exemple 40 colonnes et 25 positions de ligne. Il y a plusieurs façons de procéder.

Une façon - faites ce que j'ai fait le modèle TRS80. Un groupe de 74161 compteurs avec un assortiment de portes a généré l'adresse vidéo; trois 74157 multiplexés sur 12 bits de l'adresse CPU avec l'adresse vidéo, pour envoyer une adresse à une RAM statique 2K. Les données de la RAM ont été mises en mémoire tampon dans le CPU, mais alimentées sans tampon en tant qu'adresse de la ROM du jeu de caractères. Il n'y a pas eu d'arbitrage en bus; si le processeur voulait de la RAM vidéo, le système vidéo a été mis en marche, ce qui a entraîné l'effet «neige». L'adresse vidéo multiplexée a été combinée avec quelques lignes de la section compteur pour compléter les adresses basses; la sortie de la ROM de caractères a été transférée dans un registre à décalage 74166. Le tout s'est échappé des divisions d'un cristal de 14,31818 MHz. Dans cette approche, vous auriez exactement un mode vidéo complètement implémenté dans le matériel, comme 40x25 ou 64x16, etc.,

Une autre façon - déterrer une soi-disant puce CRTC comme une 6845. Celles-ci combinaient la plupart de la logique de compteur et de colle, et fournissaient au processeur une interface de registre de contrôle afin que vous puissiez reprogrammer une partie de la synchronisation. Des systèmes comme celui-ci pourraient être rendus quelque peu plus flexibles, par exemple, vous pourriez obtenir 40x25 et 80x25 avec le même matériel, sous le contrôle du registre. Si vous maîtrisez les fréquences d'horloge, vous pourrez peut-être laisser votre processeur avoir un accès gratuit à la RAM vidéo pendant une moitié de l'horloge et l'accès au générateur d'adresses vidéo pendant l'autre moitié de l'horloge, évitant ainsi la nécessité d'un arbitrage de bus et éliminer l'effet neige.

Si vous voulez opter pour de véritables modes graphiques, vous constaterez rapidement que rouler votre propre est problématique. L'Apple 2 d'origine le gérait, mais ce système contenait quelque chose comme 110 puces TTL MSI, et même ainsi, il y avait des choses amusantes à gérer, comme un mappage non linéaire du tampon vidéo sur l'écran et des palettes de couleurs extrêmement limitées , pour n'en nommer que deux. Et Woz est généralement reconnu comme ayant eu un indice. Au moment où le «2e» est arrivé, Apple mettait déjà le système vidéo dans une puce personnalisée. Le C-64, sorti à peu près au même moment, devait ses capacités graphiques à des puces personnalisées.

Alors .. je dirais qu'il y a deux façons de le faire. Unidirectionnel - sortez votre seau de vieux TTL et aspirez à un affichage de texte monochrome 80x25; dans l'autre sens - procurez-vous une bonne carte d'évaluation FPGA, faites le tout en VHDL et commencez avec un affichage de texte 80x25.

Vous devrez commencer par quelques principes fondamentaux de l'architecture informatique et, en parallèle, commencer avec la conception ASIC de base à l'aide de VHDL ou d'un autre langage de description.

Une fois que vous aurez appris les bases de l'architecture informatique, je vous recommanderais de vous lancer dans l'infographie, en commençant peut-être par quelques projets OpenGL simples. Le principal point à retenir ici serait de se faire une idée de l' architecture de rendu du pipeline graphique .

L'étape suivante consisterait à réfléchir aux moyens de réaliser ce pipeline de rendu avec du matériel dédié plutôt qu'avec des logiciels.

En termes de construction d'un GPU et de connexion à votre ordinateur, je ne pense pas que ce soit faisable avec le budget d'un passionné, mais il y a peut-être quelque chose de très basique que vous pouvez essayer avec une plate-forme ARM-linux intégrée (qui expose un bus système) et un FPGA (le FPGA dans ce cas étant votre GPU écrit en VHDL) produisant une sortie vers un écran VGA basse résolution en tant que projet à égalité. Cela nécessiterait également d'écrire des pilotes. Si vous pouvez le faire, ce serait un tueur sur un CV.

Regardez les diagrammes de blocs de haut niveau des GPU d'AMD et de NVidia. Vous trouverez probablement beaucoup d'informations des gens d'opengraphics, qui conçoivent du matériel graphique open source, avec des pilotes open source.

Ensuite, vous devez regarder ce que vous voulez.

• Sortie, HDMI, DVI ou VGA?
• Transformations de sommet?
• Texturer?
• Pixel Shading?
• Découpage et tramage de triangle?
• Toute texturation?
• Opérations raster?

Si vous n'avez fait aucune programmation à l'aide des fonctionnalités GPU, cela peut également être une bonne chose à savoir.

Je pense que Leon a également réussi. J'utiliserais Verilog si je faisais cela.

Si vous ne voulez qu'une vidéo compsite, comme dans la vidéo que vous avez publiée. Il existe de nombreux exemples. Heck, regardez la mise en œuvre par Woz de l'Apple II. :)

On dirait que vous ne cherchez pas à faire un GPU (dans le sens de la 3D et de l'ombrage tout ça) autant qu'un générateur vidéo. De nombreuses cartes d'évaluation FPGA ont un connecteur pour un moniteur VGA ou autre type et des exemples de projets du fabricant ou d'autres utilisateurs pour afficher des choses sur ce moniteur. Il existe également des cartes avec des écrans LCD intégrés, mais ils ont tendance à être dans la classe 300 $ et plus, tandis que ceux de base qui peuvent piloter un moniteur standard vont de 60 à 120 $.

La plupart des FGPA n'ont pas assez de mémoire interne pour faire plus qu'un petit écran, mais la plupart des cartes ont des mémoires externes avec plus de capacité. Beaucoup d'entre eux pilotent numériquement des moniteurs VGA analogiques, c'est-à-dire que RG et B sont soit complètement activés soit complètement désactivés, bien que certains vous donnent deux niveaux et vous pouvez probablement en trouver un avec un DAC vidéo ou un connecteur pour une interface de moniteur numérique.