Themenwunsch RISC-V

[chartmix]

Mich würde es freuen, wenn ihr öfters über RISC-V-Neuerungen berichtet. Zudem wäre ein Überblick über den Stand der Entwicklung sowie die aktuellen und potentiellen Einsatzgebiete von RISC-V wünschenswert. Die werden ja immer mehr eingesetzt z.B. in ssds.
Könntet ihr euch da ein bisschen mehr reinfuchsen?

 

[konkretor]

Würde ich mir auch mehr wünschen, vielleicht machen wir unseren eigenen Thread auf wo wir alles sammeln was wir finden :-)

 

[lanse]

Für den (ersten) allgemeinen Überblick empfehle ich diesen Vortrag der Legende (RISC, RAID) David A. Patterson:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Stellenweise nicht nur informativ, sondern sogar unterhaltsam.

 

[lanse]

Interessante Neuigkeiten zum Thema "RISC-V als Basis für eine Open-Source-GPU":
https://heise.de/-5039393
https://www.eetimes.com/rv64x-a-free-open-source-gpu-for-risc-v/

Dieser "Fused CPU-GPU ISA"-Ansatz entspricht ganz der RISC-V-Philosophie:

Among the advantages of fused CPU-GPU ISA is the ability to implement a standard graphics pipeline in microcode, provide support for custom shaders and implement ray-tracing extensions. It also supports vectors for numerical simulations with 8-bit integer data types for AI and machine learning.

Mit RISC-V als gemeinsamer Basis für CPU und GPU dürfte sich auch das Offloading zur GPU vereinfachen/beschleunigen lassen.

 

[Piktogramm]

Das Auslagern von Rechenaufgaben auf die GPU wird dadurch nicht einfacher. Der größte Unterschied CPU/GPU ist ja, dass die GPUs intern massiv parallel arbeiten während CPUs eher sequentiell vorgehen. Da muss man schon passend Code schreiben, damit es auf dem einem oder Anderem ordentlich skaliert. Welche ISA da am Schluss drunter liegt ist vergleichsweise egal.

Und das sich RISC-V für GPUs nutzen lässt, RISC-V definiert einfach nur grundlegende Features, die in so ziemlich jedem Rechenwerk vorhanden sein sollten. Das man da mit Erweiterungen auch GPUs draus basteln kann, sei es drum, der Code läuft dann auf kaum "normalen" Risc-V CPUs. Vor allem das dieses RISC-V64X schon von der Standardlänge von 32bit je Befehl abweicht und eigene 64bitige Befehle vorsieht. Ohne da jetzt noch mehr Zeit drauf zu werfen, die R64X ISA wird wahrscheinlich auch nicht die selben 32Register wie normales Risc-V vorsehen. Das wäre wohl recht unüblich. AMDs RDNA1 hat zb 106 "general purpose registers" [1] + massig Statusregister und sonstigen "Kram".

[1] https://developer.amd.com/wp-content/resources/RDNA_Shader_ISA.pdf

 

[lanse]

Danke, hilft mir, die Sache etwas besser zu verstehen.
Dann gibt es also vermutlich gar keinen speziellen technischen Grund, RISC-V als Basis zu nehmen, sondern man will möglicherweise einfach nur Synergien nutzen … d. h. das RISC-V-Ökosystem, z. B. die Vorarbeit, die bereits in essentieller Funktionalität und den Compilern steckt.
Bin auf jeden Fall auf die erste Implementierung gespannt, so sie denn kommt … und natürlich erst einmal darauf, ob aus dem Projekt eine offizielle RISC-V-Working-Group und aus RV64X eine Standard Extension wird.

 

[Piktogramm]

Nunja, der Aufbau ist ja eine simple RISC-V CPU mit einem deutlich größerem RV64X Co-Prozessor zu verbinden. Der CPU-Teil ist dann für Verwaltungsaufgaben zuständig. Der Co-Prozessor jedoch für alle Rechenaufgaben, wobei RV64X mit der Befehlbreite so weit von den 32bit RiscV Befehlen abweicht, dass ich das eher als eigenständige ISA betrachten würde. Zudem RV64X nach meiner Erwartung schon nicht die normale RISC-V Register nutzen wird. Es ist damit auf keinen Fall eine Standard konforme Extension und auf Seite der Compiler wird sich da auch nur das Grundgerüst teilen lassen, welches sich x86, ARM, MIPS, Risc-V, RDNA1 etc. pp sowieso schon teilen.

Das die Verwaltungslogikg RISC-V ist, wird sich daraus ergeben, dass die ISA kostenlos ist und die simplen Designs recht schnell erstellt/angepasst sind. Zudem ist RISC-V gerade auch in den Bingokarten der Investoren. Das die Eigene GPU-ISA dann namentlich an RISC-V angelehnt wird, ergibt sich wahrscheinlich auch daraus.

 

[lanse]

Der Co-Prozessor jedoch für alle Rechenaufgaben, wobei RV64X mit der Befehlbreite so weit von den 32bit RiscV Befehlen abweicht, dass ich das eher als eigenständige ISA betrachten würde. Zudem RV64X nach meiner Erwartung schon nicht die normale RISC-V Register nutzen wird.

Sicher nicht. Dabei aber bitte nicht vergessen, dass RV64X auf der (standardisierten … na ja, aktuell zumindest als Draft) RISC-V Vector Extension (RVV) basiert. Dass SIMD-Teil und skalarer Teil einer CPU nicht dieselben Register verwenden, ist ja nicht so ungewöhnlich. (Obwohl das bei RISC-V ursprünglich sogar mal so vorgesehen war: "Packed SIMD" - mehr oder weniger aufgegeben zugunsten der RVV.)
Allerdings ist vorgesehen, dass der SIMD-Teil (RVV oder RV64X) nicht unabhängig vom skalaren Teil der RISC-V-ISA (in dem Fall vermutlich nur für Verwaltungsaufgaben, wie Du richtig schreibst) existieren soll. Die EE Times nennt das "fused CPU-GPU ISA", eigentlich ist es aber einfach nur das Modularitätsprinzip entsprechend der RISC-V-Philosophie. Wie viel RVV genau in RV64X steckt und welche Synergien sich ggf. daraus ergeben, ist zur Zeit noch Spekulation. Hier noch mal die entsprechende Passage aus dem EE Times Artikel:

Spoiler: RV64X: A Free, Open Source GPU for RISC-V

These new instructions are built on the RISC-V base vector instruction set. They will add support for new data types that are graphics specific as layered extensions in the spirit of the core RISC-V instruction set architecture (ISA). Vectors, transcendental math, pixel, and textures and Z/Frame buffer operations are supported. It can be a fused CPU-GPU ISA.

Das die Verwaltungslogikg RISC-V ist, wird sich daraus ergeben, dass die ISA kostenlos ist und die simplen Designs recht schnell erstellt/angepasst sind. Zudem ist RISC-V gerade auch in den Bingokarten der Investoren. Das die Eigene GPU-ISA dann namentlich an RISC-V angelehnt wird, ergibt sich wahrscheinlich auch daraus.

Die Erwartung der Macher selbst an ihre Extension und den zu erwartenden Benefit aufgrund der Wahl von RISC-V/RVV als Basis geht aus einer Vortragsankündigung zum letzten RISC-V Workshop hervor: (Der komplette Vortrag ist leider noch nicht online verfügbar … to the public.)

Spoiler: Graphics Processing Extension RISC-V

A RISC-V ISA extension for 3D graphics would resolve many ecosystem problems while promoting the creation of new use cases and end products. The same programming language could be used on both the CPU and GPU. The GPU should be scalable similar to what has been seen in RISC-V processor cores and can be optimized for specific graphics and accelerated computing needs as a result. The ISA extension for the GPU can be integrated into the compiler to optimize computations without effort from the developer.

 

[lanse]

Weil im Zusammenhang mit dem Thema "RV64X: A Free, Open Source GPU for RISC-V" auch von der RISC-V Vector Extension (RVV) die Rede ist, hier noch ein interessanter Link dazu:
https://gms.tf/riscv-vector.html

Die RVV ist nämlich ein absolutes Highlight der RISC-V-ISA:
Während bei Intel (MMX, SSE, AVX, AVX512) und Arm (Neon, SVE, MVE) fixe Befehlssätze und fixe Vektorregister-Längen verwendet werden, ist der Befehlssatz von RVV erweiterbar und die Vektorregister-Länge variabel:

Spoiler: The Solution: Agnosticism

The solution … to all these SIMD challenges … is to design a variable length vector instruction set. In that way the instructions are then agnostic to the vector register size of a concrete CPU implementation. Thus, the binary code is portable between low, middle and high-end CPUs, and automatically makes use of wider registers in newer CPUs.
…

Ohne Rekompilierung des Quellcodes kann Binärcode, der auf einer "schwächeren" RVV läuft, also auch auf einer "stärkeren" laufen.
Bei der Intel-Plattform wird wertvolles Transistor-Budget für die parallele Implementierung von MMX und SSE und AVX verschwendet.

Intel und Arm wollen das so, damit sie immer wieder IP-Rechte an ihren Plattformen mit neuen, von ihrem Marketing in den Markt gedrückten Erweiterungen erneuern können, bevor der Patentschutz ausläuft. Bei RISC-V müssen sie auf solche (nicht technischen) Überlegungen keine Rücksicht nehmen und können ihre Vector Extension zu Ende denken. Besonders die Developer werden es ihnen danken … später sicher auch mal die Anwender …

 

[Piktogramm]

Die (draft) Vector Extension bleibt wenigstens bei 32bit Befehlslänge, die RISC-V vorsieht. Wobei diese Erweiterung analog zu dem aufgebaut scheint, war ARM mit SVE anbietet. Wo ein und der selbe Code auf Implementierungen mit unterschiedlich großen Registern laufen kann.Soweit so gut. Pixilica, die auch an RV64V arbeiten, haben schon RV32X im Angebot, da bleiben sie bei den 32bit Befehlen:

https://b5792ddd-543e-4dd4-9b97-fe2...d/841f2a_c8685ced353b4c3ea20dbb993c4d4d18.pdf
gefunden auf https://www.pixilica.com/copy-of-home

Bei RV64X muss jedoch grundlegend mit der RISC-V gebrochen. Das kann keine Erweiterung werden, bis nicht die fundamentale Spec. von RISC-V geändert wird. Wobei genau dieser Teil eigentlich "frozen" ist. Damit bleibt es für mich eine eigene ISA, mag an Kompatibilität zu RiscV angelehnt sein, aber mehr auch nicht.

Wo den Vergleich zu ARM und Intel/x86 ziehst. ARMs SVE ist wie gesagt ähnlich konzipiert, die denken das schon auch "zuende". Bei x86 ist es auch nicht so extrem schlimm. Gut da gibt es allerhand Altlasten von 3Dnow, MMX und zig Versionen SSE + AVX. Jedoch ist es prinzipiell möglich große AVX Befehle aufzuteilen. Das wurde ja unter anderem bei AMDs Zen1 gemacht, wo AVX2 Befehle mit 256bit Daten in 2x 128bit Ausführung zerlegt wurden. Wobei das natürlich die Ausführungsgeschwindigkeit ebenso halbiert, das Teilen sich aber alle erwähnten Lösungen.

Und wenn RISC-V und ARM anfangen 512bit breite Register zu verbauen um entsprechend dicke Vektoren rechnen zu können, dann wird das ebenso enorm Fläche auf dem Die benötigen.

 

[lanse]

Bei RV64X muss jedoch grundlegend mit der RISC-V gebrochen. Das kann keine Erweiterung werden, bis nicht die fundamentale Spec. von RISC-V geändert wird. Wobei genau dieser Teil eigentlich "frozen" ist. Damit bleibt es für mich eine eigene ISA, mag an Kompatibilität zu RiscV angelehnt sein, aber mehr auch nicht.

Da muss ich Dir (leider) recht geben. Ich halte es auch für vollkommen ausgeschlossen, dass die "frozen" Spec dafür noch einmal angefasst wird. Bliebe die Möglichkeit einer gewissen Abwärtskompatibilität von RV64X.
Eine freie und möglichst gut in das RISC-V-Ökosystem eingebundene GPU halte ich aber für sehr erstrebenswert. Ich fühle mich ein wenig unbehaglich bei der Sache, wenn ausgerechnet Imagination - bei Apple rausgeflogen und nicht gerade dafür bekannt, free/open-source-friendly zu sein - aktuell als iGPU-Partner bei verschiedenen interessanten RISC-V-Anbietern/-Projekten (SiFive, PicoRio, BeagleBoard) in Erscheinung tritt.

Wo den Vergleich zu ARM und Intel/x86 ziehst. ARMs SVE ist wie gesagt ähnlich konzipiert, die denken das schon auch "zuende".

SVE scheint aber nur für HPC und Server (Neoverse) vorgesehen zu sein (und ähnelt in der Tat RVV), Neon nur für Cortex-A (dürfte uns also vor allem in unseren Endgeräten begegnen) und MVE (mit Ähnlichkeiten zu RISC-V-"Packed SIMD") nur für Cortex-M. Das sind drei unterschiedliche Programmiermodelle/Befehlssätze.
Mit RVV schaffen sie es, alles von Embedded bis HPC abzudecken - notfalls ist sogar der Binärcode portierbar (natürlich nur von Embedded/Industrial über Consumer in Richtung HPC).
Selbstverständlich profitieren sie bei RISC-V hier auch von der "Gnade der späten Geburt": Wenn an der RVV Spec nicht zuletzt ehemalige Intel-Ingenieure (mit der SIMD-Fragmentierung bei x64 vor Augen) und Leute aus dem universitären HPC-Umfeld arbeiten, ist es klar, dass der verfolgte Ansatz großen Wert auf Flexibilität (Skalierbarkeit/Erweiterbarkeit) mit Langzeitperspektive, Effizienz und Entwickler-Freundlichkeit legt.
Außerdem steht RVV schon relativ früh zur Verfügung, also bereits für die zweite Generation der CPU-Designs, das hat bei Intel und ARM wesentlich länger gedauert.
Ich prophezeie, dass das für alle Anwendungsbereiche einheitliche Programmiermodell und die frühe Verfügbarkeit der Spec dafür sorgen werden, dass RVV wesentlich besser von den Entwicklern angenommen und deshalb auch mehr genutzt wird als die SIMD-Erweiterungen der Konkurrenz. Nicht zuletzt die intensive Arbeit an den (freien) Compilern stimmt da hoffnungsvoll.
(Intel ist sich ja des Problems durchaus auch bewusst und versucht jetzt, mit oneAPI schlecht genutztem Chip-Silizium mehr Arbeit zu verschaffen … reichlich spät allerdings.)