Computerwetenschapper krijgt AMD Radeon RX 6700 XT werkend op RISC-V-pc

Computerwetenschapper René Rebe heeft een AMD Radeon RX 6700 XT-videokaart werkend gekregen op de HiFive Unmatched-RISC-V-pc van SiFive. Daarvoor heeft hij naar eigen zeggen tien uur lang gewerkt aan het patchen van de Linux-kernel.

Via deze patches wist Rebe ondersteuning voor de desktopvideokaart van AMD en de Mesa Gallium 21.1.5-driver toe te voegen aan de Linux-kernel, zo legt hij uit in een YouTube-video. Daarmee wist hij de de AMD Radeon RX 6700 XT werkend te krijgen via het PCIe 3.0-slot van het HiFive Unmatched-ontwikkelbord, dat beschikt over acht bruikbare PCIe 3.0-lanes.

René Rebe heeft de AMD Radeon RX 6700 XT niet alleen gebruikt om een Linux-installatie met grafische interface op te starten. De computerwetenschapper heeft de gpu ook gebruikt voor het renderen van 3d-beelden met hardwareversnelling en het decoderen van video's. Het zou de eerste keer zijn dat een desktop-gpu is gecombineerd met een RISC-V-systeem. Rebe heeft de gpu niet kunnen gebruiken voor het spelen van games.

Het HiFive Unmatched-ontwikkelbord van SiFive is volgens de maker 'de eerste RISC-V-computer'. Het systeem omvat een Mini-ITX-moederbord met geïntegreerde Freedom U740-soc, dat beschikt over vier SiFive U74-cores en een enkele SiFive S7-kern. Het systeem heeft verder 16GB DDR4-geheugen, een PCIe 3.0-connector en twee M.2-aansluitingen, die respectievelijk gebruikt worden voor een ssd en een wifimodule. Verder heeft het ontwikkelbord vier USB 3.2 Gen 1-aansluitingen, een RJ45-connector voor gigabitethernet en een microSD-kaartlezer.

Het systeem ondersteunt Linux-distributies als Debian, Fedora en Yocto en heeft een adviesprijs van 665 dollar. SiFive introduceerde het HiFive Unmatched-ontwikkelbord in oktober vorig jaar en verscheepte eind juni de eerste systemen naar gebruikers. Het systeem is uitgebracht als platform voor ontwikkelaars. Het product is dus niet bedoeld voor regulier desktopgebruik door consumenten.

Reacties (57)

Ik ben onder de indruk van dit staaltje patchen want ik volg ook Jeff Geerling's pogingen om een GPU op een Raspberry Pi4 Compute module met PCI-E uitbreidingskaart aan de praat te krijgen.
Geen succes, terwijl de RPi een hele community met al jaren van ervaringen achter zich heeft. Heeft iets te maken met BAR Space en memory mapping, wat blijkbaar geen probleem is met deze RISC-V unit. Goed Nieuws voor RISC-V

[Reactie gewijzigd door XanderDrake op 24 juli 2021 16:57]

Je volgt blijkbaar niet wat hij doet en maakt/post voor de community?!

Hij heeft ook nooit gezegd dat hij goed was in coden. Het mooie van zijn YouTube channel is, is dat hij aan het leren is tijdens het maken van de filmpjes, en dat is een mooie manier van leren.

Dat is idd leuk te zien, als het een beetje serieus gebeurt. De indruk die thczer13 hier geeft is precies het probleem vandaag de dag, verwachten dat alles altijd perfect is, je niet hoeft te leren en als dat moet, vooral niet laten zien als je iets niet weet.

Jeff Geerling krijgt heel veel hulp van buitenaf. In het begin wist hij volgens mij nog niet eens hoe je Github moest gebruiken, en nu heeft ie z'n eigen repo's, veel contributors van zijn YT community, etc etc voor zijn YouTube projecten. Ik vind dat alleen maar mooi om te zien.

Intussen heeft ie ook veel geleerd over Linux en z'n eigen kernels gecompileerd om zo GPU's draaiend te krijgen op de RPi. Hij zegt ook nadrukkeljik in een aantal van zijn filmpjes dat hij weinig ervaring heeft met programmeren.

[Reactie gewijzigd door MrFax op 25 juli 2021 16:06]

Juist, ik kan dat alleen maar top vinden, zo zijn er velen (waaronder ik).

Weer vrij foute kop boven dit artikel. Die man heeft helemaal geen "AMD Radeon RX 6700 XT werkend gekregen op een RISC-V-pc". Dat is een RISC-V systeem met PCIe 3.0-slot waarin een PCIe complaint Radeon gestoken is. Hardware matig werkt dat zondermeer als alles volgens de geldende standaard werkt.

Dat hij hiervoor SOFTWARE support in de gebruikte Linux distro werkende heeft gekregen is wat anders.

Dat noemen ze een driver schrijven of een bestaande driver patchen.

Leuk projectje en mooi resultaat ? Zeker, maar niet zo spectaculair als het klinkt.

Dat het past maakt het dan niet per se werkend. De Raspberry Pi CM4 heeft ook een PCI-e slot op het standaard devboard, waar je ook een gpu in kunt zetten. Maar het werkt niet. Het werkt pas als je een werkende driver hebt, waardoor de CPU met de GPU kan communiceren. Standaard is het niet zo, en deze man heeft dat dus wel laten werken. Titel klopt dus gewoon.

Ik heb zo geen bordje of ik kon het zelf testen, maar ik ben 99,9% zeker dat die kaart probleemloos een very basic VGA beeld geeft bij het aanzetten.

Wat jij insinueert is dat het bordje de kaart niet eens zou herkennen hardware matig. Als dat het geval was komt er heel wat meer bij kijken en zou het wel een knappe prestatie zijn. Maar dan zo er een groot probleem zijn wegens het niet conform zijn aan de PCIe standaard.

Maar dit is nu duidelijk niet het geval.

En een GPU op je RPi bordje werkt qua hardware perfect. Anders zou het niet lukken met een driver...

Bij mijn weten specificeert de pci standaard niets specifiek grafisch, en zou het zonder drivers simpelweg geen output moeten geven tot je jouw systeem verteld hoe je met dat specifieke pci apparaat moet communiceren, en dus driver.
Dit is puur op basis van wat ik mij van de pci spec herinner, dus ik kan er naast zitten

De PCIe bus en elke kaart erin moet geinitialiseerd worden. Hiervoor wordt doorgaans de firmware op de betreffende kaart aangesproken. Hier bestaat een standaard bootstrap procedure voor, maakt niet uit wat voor soort kaart het is.

Er is een groot verschil tussen het initialiseren van een card, en een driver om alle functies van die kaart te benutten. Een kaart werkt als het bord dus correct de PCIe bus initialiseert en de kaart een correcte terugmelding geeft.

Je zou verwachten dat men dit onderscheid ook hier maakt, maar aan veel reacties te zien hebben de meeste mensen geen benul van hoe dit werkt, en willen ze het ook niet weten.

Er is een groot verschil tussen het initialiseren van een card, en een driver om alle functies van die kaart te benutten. Een kaart werkt als het bord dus correct de PCIe bus initialiseert en de kaart een correcte terugmelding geeft.

Er is werken en werken, volgens jouw definitie werkt een PCIe kaart als die zich netjes aan het PCIe protocol houdt, en het mainboard waar hij insteekt ook.
De eindgebruiker zal het hier echter niet met je eens zijn, die wil graag dat zijn desktop goed te gebruiken is in combinatie met de kaart, en daarbij geen storende bijverschijnselen laat zien.
Voor dat laatste zal er behalve goede desktop software (xorg/wayland & gnome/kde/...) ook een belangrijk deel van de GPU features via een driver ter beschikking worden gesteld aan de grafische omgeving.
Een driver fixen die voorheen niet werkte, kan in die context dus wel degelijk worden beschouwd als een 'Grafische kaart werkend krijgen'.

Ik denk dat hij net als de meeste mensen iets pas als werend beschouwd als hij het gewoon kan aansluiten en gaan. Als er geen driver support is 'werkt' het dus niet.

Jij lijkt te beweren dat drivers eigenlijk overbodig zijn of zo.

Wat ik dan weer raar vindt is waarom je de kernel zou moeten patchen om een driver te kunnen maken voor een stukje hardware.... Klinkt niet echt logisch eigenlijk. Ik zou hopen dat de kernel daarvoor onaangeroerd kon blijven.

Linux is een monolithische kernel. Alle drivers voor alles zijn onderdeel van de kernel.

Leuk, maar zonder driver geen beeld, zonder beeld heeft het niet veel nut natuurlijk. Dat de kaart netjes in het slot past en het slot voldoet aan de PCIe standaard betekend nog niet dat de kaart zelf ook maar enig werk kan verzetten. De software kant moet ook nog iets kunnen doen. En de PCIe standaard is nu weer niet opgesteld op zo een manier dat je er onmiddelijk beeld uit gaat krijgen.

Door het patchen van de kernel heeft hij dus wel degelijk deze videokaart, en andere kaarten op dezelfde architectuur, werkende gekregen op de RISC-V instructieset. Daarvoor was er onvoldoende ondersteuning in de volledige stack om beeld uit deze kaarten te krijgen.

Zelfs een RX 6700 XT is in de basis nog steeds een VGA kaart die voldoet aan de oeroude basics van een VGA kaart. En zelfs deze kaart zal met een basic VGA driver gewoon beeld geven. Zoniet zou je er niet eens je BIOS scherm op kunnen krijgen.

Dat je voor enkel maar beeld geen RX 6700 XT installeert is logisch, en dat er wat meer nodig is om het potentieel van deze kaart te benutten is ook logisch.

Maar dat maakt het allemaal nog geen waanzinnige resultaat.

Heb je enig idee wat er vandaag de dag nog ontworpen en gemaakt wordt in de C64 en Amiga scene ? De meest waanzinnige moderne devices die men aan een C64 of Amiga hangt en een zelf drivers en software voor schrijft ?

IMHO zitten daar straffere dingen tussen dan een bestaande driver patchen...

De meeste andere architecturen werken anders,
Risc-V geen ervaring mee,
Maar heb hier zelf een Spar64 en kan je vertellen dat als je deze kaart aansluit je geen beeld zult krijgen zelfs geen basic VGA zonder drivers.
En klopt je kunt dan niet in de bios komen, dat hoeft ook niet want deze systemen hebben geen bios.
Terwijl deze kaart mits je goede drivers hebt best op Sparc64 kunnen draaien

Zoals Blokker al zei moet de softwarekant ook meewerken op RISC-V. Logisch ook: een chirurg snijdt je toch ook niet open om een harttransplantatie te doen als je hersenen de boel niet kunnen aansturen? Er moet een aansturing zijn en op RISC-V is dat de driver.

Er is een groot verschil tussen een kaart 'aan het werk krijgen' en een 'driver geport krijgen'...

Er is een groot verschil tussen een kaart 'aan het werk krijgen' en een 'driver geport krijgen'...

Wat je bedoelt is, er is een groot verschil tussen 'hardware werkend krijgen' en 'software werkend krijgen'.
Beiden zijn echter nodig voor een werkend eindresultaat.

Bovendien is 10 uur werk te beschouwen als een vlot klusje.

Wat een onzin. Onder "werkend" zou ieder weldenkend mens verstaan dat het voor het beoogde doel gebruikt kan worden: beeld op je scherm toveren. Daar hoort dus ook gewoon de software-aansturing bij.

Dat is wel echt muggenziften hoor. Inderdaad, zonder drivers wordt deze kaart al correct van stroom voorzien en misschien geeft ie zelfs beeld, maar hij heeft de kaart daadwerkelijk aan het werk gezet. Het lijkt me dan niet heel overdreven om te zeggen dat hij hem "werkend" heeft gekregen. Dat hij daarvoor niet heeft hoeven solderen o.i.d. lijkt me niet zo relevant, want dat wordt ook nergens beweerd.

Natuurlijk is het nog knapper als je een videokaart werkend krijgt op een broodrooster, maar deze kop is echt prima zo.

Bedankt namens deze leek op dit gebied.

[quote]
een RISC-V systeem met PCIe 3.0-slot waarin een PCIe complaint Radeon gestoken is
[/quote]

Gewoon een RISC-V-pc dus? Of noem je conventionele desktop-pc's ook "een AMD64 systeem met PCIe slots"?

Ik had je comment verkeerd geïnterpreteerd, excuses

[Reactie gewijzigd door kornelisjann op 24 juli 2021 17:03]

clickbait is niks nieuws op tweakers.

Ik had eigenlijk wel verwacht dat de Mesa driver van AMD gewoon zou compilen naar RISC-V, zoals dit bij ARM ook het geval is, maar blijkbaar was er meer werk nodig? In ieder geval impressive dat ie hem als nog aan de praat heeft gekregen!

Zo'n driver zal honderden zo niet duizenden hacks gebruiken die CPU specifiek zijn.

Zo'n driver zal honderden zo niet duizenden hacks gebruiken die CPU specifiek zijn.

Hacks zou ik het niet onmiddelijk noemen, maar er kunnen inderdaad wel vele platformspecifieke calls inzitten die voor de RISC-V architectuur nog niet bestaan. Dan moet je die dus eerst zelf in de kernel gaan patchen danwel workarounds voor gaan zoeken.

Vaak hoeven dit soort calls nog niet eens platformspecifiek te zijn, maar worden (bijvoorbeeld uit onwetenheid) wel bepaalde aannames gedaan in de low-level code van de drivers. Zo wordt er bijvoorbeeld bij de Nouveau driver (open source nvidia driver) uit gegaan van een page size van 4K (standaard op X86, maar bijv. niet op PowerPC). Zie ook dit bug report..

Een ander voorbeeld is verschil in endiannes (volgorde van de bitjes): als de ene architectuur links begint met lezen van het 'most significant'/meest grote bitje (Big Endian), en de andere architectuur juist rechts begint (Little Endian) kunnen er hele rare dingen gebeuren als je hier in je low level code geen rekening mee houdt.

Veel hardware is gebouwd om maar op een paar manieren samen te werken met de rest. Videokaarten hebben bijvoorbeeld een eigen BIOS die kort bij het opstarten van een PC (gedeeltelijk) de controle krijgt. Als de firmware op de kaart daar vanuit gaat, en RISC-V niet op die manier opstart heb je een probleem.

Zo zijn er wel meer beperkingen die ontstaan uit legacy-technologie die in stand wordt gehouden waar RISC-V juist die legacy wil weggooien en een schone start wil maken.

Het omcompilen van de driver is de eerste stap, en een behoorlijke stap ook, maar nu komt het vervelende gedeelte, de lijmcode schrijven die de nieuwe architectuur goed werkend krijgt.

Het is vooral het glad strijken van de i/o kanalen. Bedenk dat je een uitbreidingskaart voor een pc aan een raspberry-pi wilt koppelen. Dat is een heel andere steek en heel andere i/o kanalen. Blijkbaar was de hardware aansluiting nog wel te doen, het adresseren van de hardware is iets anders.

En zeker met een gpu en een cpu die op 1 of andere manier met shared i/o werken is het aansturen ook best wel spannend.

Pas nadat de i/o adressering is verwerkt begint het compileren.

Het is vooral het glad strijken van de i/o kanalen. Bedenk dat je een uitbreidingskaart voor een pc aan een raspberry-pi wilt koppelen. Dat is een heel andere steek en heel andere i/o kanalen. Blijkbaar was de hardware aansluiting nog wel te doen, het adresseren van de hardware is iets anders.

Is dat niet meer een kwestie van goede PCIe drivers? Daar wordt hier verder echter niets over gezegd.
Hetgeen natuurlijk niet betekend dat daar niets gebeurt is, er is immers sprake van 'kernel patches'.

Naar mijn idee doen de drivers alles met het verkeer dat over die bussen gaat. Maar de drivers moet nog wel worden aangegeven waar/hoe de kanalen gevonden worden. Misschien ligt het er maar net aan waar je de grens legt. Er moet in ieder geval worden aangegeven dat de communicatie over bepaalde kanalen gaat. En dat moet allemaal werken en niet botsen met wat er elders al werkt en nog meer van dat soort zaken. Of dat in de driver zit, of bij de installatie wordt ingesteld of bij het opstarten wordt uitgezocht of live kan veranderen... dat moet allemaal worden nagezien en verbeterd.

Mooie reclame voor RISC-V, zeker omdat Nvidia wellicht ARM over neemt. Open architectuur die uitbreidbaar is lijkt mij the way to go.

Ik zie niet direct in hoe dit reclame is voor de architectuur. Iemand heeft ervoor gezorgd dat open source drivers geport zijn naar een nieuwe instructieset. Hoewel een mooie stap vooruit is het niet uniek. En met een instructieset alleen ben je niet veel. Je hebt toch echt ondersteuning nodig van hardwarefabrikanten die ermee aan de slag willen gaan. En dan is de vraag waarom zij ineens naar deze nieuwe instructieset zouden moeten omschakelen. Zolang Nvidia woord houdt en de ARM instructieset blijft ontwikkelen en in licentie geven hebben zij niet direct een reden om snel de omschakeling te maken. Net zoals ARM jarenlang genegeerd is door de desktop/laptop markt.

Ik zie niet direct in hoe dit reclame is voor de architectuur.

De laatste 10 jaar wordt de gpu steeds vaker ingeschakeld voor allerlei taken die in het verleden het domein van de cpu-waren.

Op smartphones is het normaalste zaak van de wereld.

Op het moment dat je een gpu kunt koppelen aan de risc kun je op verschillende fronten sneller verder ontwikkelen. Legacy sneller eruit en sneller naar een soc met oa geïntegreerde gpu wat je soc nog krachtiger maakt.

Als het zo interessant is waarom heeft AMD dan zelf niet gewoon even een paar dagen de tijd genomen om het compatibel te maken

Dat is niet hoe open source werkt, in principe wil je geen input van bedrijven. Het is immers ook copyleft

Waarom heeft Intel geen ARM als je weet dat die binnen een decennia zo hard gegroeid is

Voorlopig zullen de grotere fabrikanten het allemaal links laten liggen en tzt misschien bijdraaien. Er is dikke kans dat de versnelling ergens uit het oosten zal komen en een concurrent product zal neerzetten.

Zoek maar eens op Xscale 😉

Met reclame bedoel ik in de zin van dat er meer hardwareondersteuning bij is gekomen.

Zolang Nvidia woord houdt en de ARM instructieset blijft ontwikkelen en in licentie geven hebben zij niet direct een reden om snel de omschakeling te maken.

Nvidia niet, maar concurrenten wel. Licentiegelden kan Nvidia natuurlijk verhogen zodra ARM is overgenomen.

Vorige week heeft iemand ook een Radeon kaart werkend gekregen in combinatie met Haiku OS: https://forums.sifive.com...-on-hifive-unmatched/4981

Vraag me af wie nou eerder was, in ieder geval goed nieuws voor het platform, kan niet wachten dat er meer hardware en software beschikbaar komt.

Haiku is niet gebaseerd op de Linux kernel.
Zie ook: https://www.haiku-os.org/about/faq/#is-haiku-based-on-linux

Klopt, is een eigen kernel.

In het artikel staat echter: "Het zou de eerste keer zijn dat een desktop-gpu is gecombineerd met een RISC-V-systeem.". En dat is dus wellicht niet waar.

Rebe heeft de gpu niet kunnen gebruiken voor het spelen van games.

Jammer van die uitgebreide library aan RISC-V 3D accelerated games die op de markt is

Ben benieuwd hoe lang het duurt voordat DooM geport wordt…

Interessant. Ik vraag me nu ook het een en ander af. Die drivers die AMD voor linux maakt zijn dat uitsluitend binaries? Ik heb even bij AMD gekeken, ik zie dat ze Ubuntu, Suse en CentOS ondersteunen. Worden die Linux drivers van AMD (met een trucje) gebruikt in andere Linux distro's? Of worden er third party drivers gebruikt in de niet ondersteunde distro's?

Ik heb zelf welleens geprobeerd om Debian aan de praat te krijgen op een laptop met een nVidia gpu. nVidia brengt geen linux drivers uit en de third party drivers zijn voor een groene Linuxgebruiker (ik) een ramp.

nVidia heeft al vele, vele jaren Linux-drivers.

En ja, de AMD-drivers worden in andere distro's met een ‘trucje’ gebruikt. Althans, vooral in de afwijkende distro's. Debian, Ubuntu en Deepin bijv. wijken in de basis niet veel van elkaar af, dus daar is geen trucje nodig.

Knap, want ik weet niet eens waar dit over gaat.

https://nl.wikipedia.org/..._instruction_set_computer

Knap, want ik weet niet eens waar dit over gaat.

Dan kan je ook niet weten of het knap is.

Welk deel begrijp je niet?