FuryGpu: maßgeschneiderte PCIe-FPGA-Grafikverarbeitungseinheit

 (furygpu.com)
1 Punkte von GN⁺ 2024-03-28 | 1 Kommentare | Auf WhatsApp teilen
  • Eine maßgeschneiderte Grafikverarbeitungseinheit, die von der Hardware bis zum Treiber selbst entwickelt wurde, um in modernen PCs wie eine echte GPU verwendet zu werden
  • Die Kernimplementierung erfolgt auf einem Xilinx Zynq UltraScale+ FPGA und ist auf einer maßgeschneiderten PCB untergebracht
  • Sie ist per PCIe mit dem Host-Computer verbunden und funktioniert nicht als Softwareexperiment, sondern als echte Hardware-GPU
  • Der Funktionsumfang ist auf das Niveau hochwertiger Grafikkarten aus der Mitte der 1990er-Jahre ausgelegt und zielt auf das Rendering damaliger Spiele ab
  • Mit einem modernen Windows-Treiber-Stack kann sie echte Spiele dieser Ära mit Bildraten über Echtzeit rendern

Hardwareaufbau

  • FuryGpu ist eine vollständig maßgeschneiderte GPU, die von Grund auf für den Einsatz in modernen Computern entwickelt wurde
  • Die Grafikverarbeitungslogik ist auf einem Xilinx Zynq UltraScale+ FPGA implementiert
  • Sie sitzt auf einer maßgeschneiderten PCB und ist per PCIe mit dem Host-Computer verbunden

Grafikfunktionen und Treiber

  • Die Hardwarefunktionen unterstützen ein Niveau, das hochwertigen Grafikkarten aus der Mitte der 1990er-Jahre entspricht
  • Zusammen mit einem modernen Windows-Software-Treiber-Stack kann sie in realen Umgebungen als GPU verwendet werden

Ausführbare Aufgaben

  • FuryGpu kann echte Spiele aus dieser Ära rendern
  • Die Rendering-Leistung kann Bildraten über Echtzeit erreichen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-28
Hacker-News-Kommentare
  • Ich bin der Macher dieses Projekts. Ich hatte gehofft, dass es erst die Runde macht, wenn auf der Website noch etwas mehr Content steht, aber nun ist es eben so gekommen :)
    Um die häufigste Frage zu beantworten: Irgendwann will ich den gesamten Stack als Open Source veröffentlichen. Dazu gehören PCB-Schaltplan/Layout, sämtliches HDL, der Windows-WDDM-Treiber, der API-Runtime-Treiber und sogar Quake, das ich auf diese API portiert habe.
    Allerdings muss ich noch rechtliche Fragen im Zusammenhang mit meiner Arbeit klären und Details wie die Lizenz festlegen. Es ist nicht mein Hauptjob, aber nah genug dran, dass ich vorsichtig sein muss.
    Der erste Commit für dieses Projekt war am 22. August 2021; ich habe etwas mehr als zweieinhalb Jahre daran gearbeitet. Ich habe währenddessen keine Artikel geschrieben, aber in der YouTube-Playlist zu FuryGpu (https://www.youtube.com/playlist?list=PL4FPA1MeZF440A9CFfMJ7...) gibt es einige Videos, in denen man den Fortschritt grob nachvollziehen kann.
    Die nächsten Blogposts werden sich mit dem PCIe-Interface befassen; daraus wird wohl eine mehrteilige Serie, die beim PCB-Schaltplan/Layout beginnt und über das FPGA-Design bis zum Windows-Treiber führt. Schon nach dem einen Artikel zur Texture Unit respektiere ich Leute noch mehr, die solche technischen Texte in regelmäßigem Rhythmus schreiben.
    • Ich habe auf Discord halbwegs regelmäßig Updates gesehen, und es ist klasse, dass das Projekt so weit gekommen ist. Gleichzeitig war es etwas frustrierend, weil mein eigenes FPGA-Projekt im selben Zeitraum vergleichsweise wenig Fortschritt gemacht hat; ich habe darauf gewartet, dass das Ganze einmal schriftlich zusammengefasst wird.
    • Ich habe nach dem Xilinx Zynq UltraScale+ gesucht, und der scheint ziemlich teuer zu sein. Viele geben für Hobbys ja Tausende Dollar oder mehr aus, also ist das kein Problem, wenn man das Geld hat. Mich würde aber interessieren, ob das die finale Ziel-Hardware des Projekts ist oder ob noch mehr geplant ist.
    • Mich würde interessieren, wie stark es auf Hard-IP-Blöcke angewiesen ist. Lässt es sich auf FPGAs anderer Anbieter wie Lattice ECP5 portieren? Ich wüsste auch gern, ob PCIe direkt in HDL implementiert wurde oder ein proprietärer IP-Block des Herstellers zum Einsatz kommt. Statistiken zur Ressourcennutzung wären ebenfalls schön.
    • Im Artikel zur Texture Unit sieht es so aus, als würde die ROM-Tabelle für die Adress-Offsets der Mip-Level ziemlich viel Platz verbrauchen. Hast du erwogen, die Mip-Basisadresse als Teil der Texturspezifikation aufzunehmen?
    • Welche Bücher würdest du empfehlen, wenn man etwas Ähnliches ausprobieren möchte? Zum Beispiel bräuchte man Material, um PCB-Board-Design für PCIe-Steckkarten-Hardware zu lernen.
  • Der Einfluss von Ben Eaters Breadboard-Computer-Serie auf Hobby-Elektronik ist erstaunlich. Ich wurde ähnlich inspiriert und wollte selbst eine „Retro“-CPU entwerfen.
    Ich wünsche mir sehnlichst etwas, das sich ähnlich einfach wie ein 6502 einstecken lässt, aber ein paar Register mehr und Features wie Hardware-Division hat – doch das ist wirklich keine Kleinigkeit.
    Am Ende landet man wieder bei „einfach einen MCU nehmen und fertig“, und danach stößt man auf das Problem der Grafikerzeugung.
    • Genau dort hat auch dieses Projekt angefangen. Nachdem ich Ben Eaters 8-Bit-Breadboard-Computer gebaut hatte, begann ich zu schauen, was man bräuchte, um etwas Interessanteres zu bauen.
      Da man mit diskreten Logikgattern nicht viel Hochgeschwindigkeitsverarbeitung machen kann, dachte ich, es wäre viel spannender zu lernen, was sich mit FPGAs machen lässt.
    • Register kann man über Stack oder Speicher umgehen, und Division kann man als einfache Funktion implementieren. Das gehört zu dem Spaß, auf dieser Ebene zu arbeiten.
      Bei Grafik kann man anfangs mit serieller Ausgabe beginnen. Das ist eine Art, das Problem zu abstrahieren, bis man bereit ist, es anzugehen. Wenn man einen Arduino maximal ausreizt, kann man daraus eine sehr einfache VGA-Grafikkarte machen [1]. ESP32 to VGA ist noch einfacher und bietet auch Tastatur und Maus [2].
      [1] https://www.instructables.com/Arduino-Basic-PC-With-VGA-Outp...
      [2] https://www.aliexpress.us/item/1005006222846299.html
    • Ich wollte den Parallax Propeller empfehlen, besonders das erste Modell im DIP-Format, aber tatsächlich ist der deutlich komplexer zu programmieren und auch wesentlich leistungsfähiger. An dem Punkt kann man sich besser gleich einen ESP32 ansehen, und dann ist man am Ende wieder bei „einfach einen MCU verwenden“ :)
      Videoausgabe ist wegen der für die digitalen Ausgänge nötigen Bandbreite ein großes Problem. Mit Composite- oder VGA-Ausgabe könnte es noch mit leicht erhältlichen Chips machbar sein. Der neuere Commander X16 hat für dieses Problem ein FPGA gewählt.
    • Mir fällt kaum ein anderes ähnlich populäres Beispiel ein. Eine Zeit lang war es ruhig, aber zuletzt hat er wieder halbwegs regelmäßig Videos hochgeladen, mit Zuschauerzahlen im niedrigen sechsstelligen Bereich.
      Tatsächlich sehen vermutlich weniger als 100.000 Menschen die Videos bis zum Ende, und von denen probieren noch weniger selbst etwas aus. Für die heutige Zeit wirkt Hobby-Elektronik überraschend klein.
    • Als ich mir Grafik auf MCUs angesehen habe, war ich enttäuscht zu erfahren, dass die kleine NeoChrom-GPU in neueren STM32-Teilen nicht vollständig dokumentiert ist. Historisch hat STM32 eher keine Black Boxes in die Chips eingebaut; vermutlich handelt es sich um einen von Dritten lizenzierten IP-Block.
  • Cool. Der Hello-Blogpost hat geholfen, die Absichten des Machers zu verstehen: https://www.furygpu.com/blog/hello
    Beim Lesen wirkt es vor allem wie ein Hobbyprojekt aus Spaß, und offenbar will er künftig viel darüber schreiben, wie er es gebaut hat.
    Besonders beeindruckend ist, dass der gesamte Stack funktioniert. Der Windows-Treiber implementiert eine Custom-Grafik-API, und darauf läuft Quake. Dass es keine DX/GL-Unterstützung gibt, ist schade, aber es ist gut nachvollziehbar, warum er den Weg über eine Custom API gewählt hat.
    Ich frage mich, ob er das Design als Open Source veröffentlichen wird.
    • Die für grundlegende D3D-Unterstützung nötigen Funktionen hinzuzufügen, wäre ein erheblicher Aufwand; ich prüfe gerade konkret, was in Sachen Performance möglich ist. Leider sieht die Prognose nicht gut aus.
      Es ist nicht einfach nur ein Problem von „Shadern“; allein der Window Manager des OS stellt ziemlich viele Anforderungen, damit er läuft. Die üblichen Akteure in diesem Bereich – also AMD, Nvidia, Intel, Imagination usw. – haben schrittweise auf Technologien aufgebaut, die sich über mehr als 20 Jahre entwickelt haben.
  • Das ist mein Traumprojekt.

Im vergangenen Jahr habe ich an einer 2D-zentrierten GPU für Mikrocontroller mit starken I/O-Beschränkungen gearbeitet (https://github.com/KallDrexx/microgpu). Damit kann man Benutzeroberflächen auf großen Displays selbst über langsame SPI-Geräte rendern, und die Arbeit war sehr spannend
Als ich aber die Grenzen der Prozessor-Pipeline gesehen habe, dachte ich immer wieder, dass man das mit einem FPGA schneller machen könnte. Kürzlich habe ich ein paar günstige FPGAs besorgt und angefangen zu lernen, um den ESP32-basierten microgpu auf FPGA-Basis umzustellen
Wegen Kindern und begrenzter Freizeit weiß ich nicht, ob ich jemals auf dieses Niveau komme, aber ich würde gern wenigstens ein Hundertstel davon schaffen

  • Ihr wisst das vermutlich schon, aber für andere, die sich für diesen Weg interessieren: Für solche Einsatzzwecke lohnt es sich auf jeden Fall, sich auf FPGAs mit dedizierten High-Bandwidth-Transceivern zu beschränken
    Schon ein „einfaches“ 1080p-RGB-60-Hz-Signal erfordert Hochfrequenz-Signalverarbeitung, die allein mit reiner FPGA-Logik sehr schwer zu bewältigen ist
  • Die Pipeline wirkt retro, ist aber viel besser als gar nichts
    Es gibt kaum nennenswerte Open-Hardware-GPUs. Je nach Lizenz mag es anders aussehen, aber ich konnte keine Informationen finden, und das hier könnte der erste Fall und ein Ausgangspunkt für mehr Arbeit sein
    • Eine GPU ähnlicher Art gibt es auch hier
      https://github.com/asicguy/gplgpu
    • Natürlich hängt es davon ab, was man unter „open“ versteht. Soweit ich weiß, gibt es für halbwegs aktuelle FPGAs keine Open-Source-Toolchain, sodass man für echte Änderungen weiterhin an proprietäre, vermutlich kostenpflichtige Tools gebunden ist. Wenn man etwas Größeres als einen iCE40 UP5k braucht, gibt es fast keinen Weg darum herum
    • Ticket2Ride Number9 war eine Fixed-Function-GPU aus den späten 1990ern und wurde vollständig unter GPL als Open Source veröffentlicht
    • Es hängt davon ab, was man als „GPU“ betrachtet
      https://github.com/schlae/graphics-gremlin ist ein MDA/CGA-kompatibler Adapter
      https://github.com/OmarMongy/VGA ist ein VGA-Core
      https://github.com/archlabo/Frix ist ein vollständiger IBM-PC-kompatibler SoC inklusive VGA
    • Es gibt auch Nyuzi, das stärker auf eine Allzweck-GPU ausgerichtet ist: https://github.com/jbush001/NyuziProcessor. Der Entwickler hat allerdings auch mit der Ausführung von 3D-Grafik experimentiert
  • Kaum zu glauben, dass das dem, was wir als kleine eigenständige GPU haben, am nächsten kommt. So etwas wie eine GPU im M.2-Format gibt es nicht
    Ich will einfach nur eine eigenständige M.2-GPU. Die Leistung darf modest sein, etwa auf dem Niveau integrierter GPUs wie Intel UHD Graphics, AMD Radeon oder Qualcomm Adreno
    Ich habe eine Idee für ein kleines Embedded-Produkt, das viel Compute und Networking braucht, aber nur sehr wenig Grafikleistung. Der NXP Layerscape LX2160A [1] wäre fast perfekt gewesen, aber weil er keine integrierte GPU hat, musste ich ihn verwerfen. Ich brauche einfach nur eine kleine GPU
    [1]: https://www.nxp.com/products/processors-and-microcontrollers...
    • Es gibt mindestens eine M.2-GPU von Asrock Rack auf Basis des Silicon-Motion-SM750-Controllers. Produkte im mPCIe-Formfaktor gibt es ähnlich ebenfalls
      Die Leistung kommt modernen integrierten GPUs bei Weitem nicht nahe. Integrierte GPUs können Systemspeicher, Cache und das Leistungsbudget vollständig nutzen, ein einfaches M.2-Gerät hat all das nicht. Selbst Low-End-PCIe-GPUs, also Single-Slot-Karten mit halber Länge/halber Bauhöhe, schaffen es kaum, gute integrierte GPUs zu übertreffen, und ergeben nur dann Sinn, wenn man unbedingt grundlegende Display-Funktionen braucht
    • Was ist mit MXM-GPUs, wie sie früher in Gaming-Laptops steckten? Ich weiß, dass der Standard sehr nischig und teuer ist. Auf eBay kostet eine gebrauchte 3080M etwa 400 Dollar, aber es gibt sie, und man kann sie auf PCIe adaptieren und dann auch per M.2 anschließen
    • Die Leistungsaufnahme könnte zu niedrig sein, aber so etwas gibt es auch: https://www.matrixorbital.com/ftdi-eve
  • Ein sehr cooles Projekt, und es ist schön, in diesem Bereich mehr Arbeit zu sehen
    Ebenfalls sehenswert ist das Vortex-Projekt der Georgia Tech [1]. Das wirkt wie ein Ansatz, der eher in die Zukunft blickt, statt die Fixed-Function-Vergangenheit des GPU-Designs zu wiederholen. Im Kern ist es ein hochgradig parallelisierter Computer auf RISC-V-Basis mit Erweiterungen, um GPU-Aufgaben besser zu bewältigen
    Die Boards, auf denen es läuft, kosten Tausende Dollar und sind daher nicht gerade hobbyfreundlich, aber sie sind definitiv zugänglicher als geschlossene proprietäre Entwicklung. Vor ein paar Monaten gab es auch ein 2.0-Release
    [1]: https://vortex.cc.gatech.edu/
  • Das sieht nach einer wirklich beeindruckenden Leistung aus. Ich würde gern Fotos des tatsächlichen Geräts sehen. Auch welches FPGA-Modul verwendet wird, ist mir etwas unklar
    Im Blog ist von einem Xilinx Kria SoM die Rede, aber wenn ich dem Link folge und mir die Modulspezifikationen ansehe, scheint dort ein ARM-SoC statt eines Xilinx-FPGA verbaut zu sein. Vielleicht übersehe ich etwas, weil ich mit der FPGA-Welt nicht vertraut bin
    https://www.amd.com/en/products/system-on-modules/kria/k26/k...

Wie an anderer Stelle in diesem Thread gesagt: Das Kria SoM ist so aufgebaut, dass es FPGA-Fabric zusammen mit einem fest verdrahteten ARM-Core für die Steuerung enthält. Abgesehen davon, dass es damals verfügbar war und das Kria-Entwicklungsboard mit etwa 350 Dollar wirklich günstig war, enthalten diese Geräte Dinge wie fest verdrahtete DisplayPort-IP am ARM-Core, sodass Aufgaben wie Videoausgabe und Audio an die Firmware abgegeben werden können
Eine frühere Version dieses Projekts lief auf einem Zynq 7020; damals musste man die HDMI-bezogenen Teile selbst schreiben. Das ist nicht extrem kompliziert, belegt aber ziemlich viel Logik, und wenn man es konfigurierbar machen will, wird es deutlich komplexer

  • Es ist nicht entweder ein ARM-SoC oder ein Xilinx-FPGA, sondern ein gemischter Chip. FPGA und klassisches SoC sind zusammengebracht, sodass man keine Softcore-MCU einbauen muss, die nur für grundlegende Verwaltungsaufgaben wertvolle FPGA-Ressourcen frisst
  • Xilinx nennt die genaue FPGA-Teilenummer, die im Kria SoM verwendet wird, nicht. Den veröffentlichten Spezifikationen nach scheint sie jedoch zu den Bausteinen ZU3EG-UBVA530-2L und ZU5EV-SFVC784-2L zu passen[1], und nur letzterer hat PCIe-Unterstützung
    Wie im Blogbeitrag beschrieben, ist schon das Entwerfen und Bring-up eines FPGA-Boards eine hohe Hürde. Es wäre schön, wenn eines Tages Schaltpläne und Quellen veröffentlicht würden
    [1] https://docs.amd.com/v/u/en-US/zynq-ultrascale-plus-product-...
  • Es hieß, die Hardware-Funktionen entsprächen denen einer High-End-Grafikkarte aus der Mitte der 1990er Jahre; ich glaube, diese Frage hat noch niemand gestellt, also möchte ich sie stellen: Wie weit geht die VGA-Kompatibilität? Könnte man sie zum Beispiel in einen beliebigen PC mit PCIe-Slot stecken, DOS booten und DOOM spielen?
  • Es wäre schön, wenn der Entwickler die Implementierung des PCIe-Interfaces ausführlich behandeln würde. Ich werde vermutlich nie Hardwarearbeit auf diesem Niveau machen, aber aus allgemeinem Bildungsinteresse lohnt sich ein Blick ins Innere von PCIe meiner Meinung nach
    • Genau darum soll es im nächsten Blogbeitrag gehen. Es wird wohl eine mehrteilige Serie; der erste Beitrag behandelt PCB-Schaltplan/Layout, der nächste das FPGA-Interface und Tests, und danach dürfte der Windows-Treiber folgen
    • Das verwendete FPGA hat natives PCIe, daher bekommt man an dieser Stelle normalerweise nur ein Interface zu einem proprietären IP-Block des Herstellers. Der Zustand offener Interfaces in der FPGA-Welt ist erbärmlich. Das Beste, was ich vollständig Open Source gesehen habe, war ungefähr ein Gigabit-MAC
    • Es wird https://github.com/alexforencich/verilog-pcie auf dem Xilinx-PCIe-Hard-IP-Core verwendet. Dieser Core liefert alles unterhalb der Transaktionsschicht