Utvecklare spelar Witcher 3 på RISC‑V

Jag är mest fundersam hur de lyckats få till drivrutiner och annat, min spontana gissning är proton+linux, annars har jag svårt att se hur de fick igång en tillräckligt stor windows runtime på riscv

Jag snabbläste bloggen och det är definitivt linux de kör

Det finns ju också specifika saker som x86 gör konstigt som minneshantering till exempel, därav vissa översättningssvårigheter

Antar en del av anledningen till så låg FPS är att de har ett "serverchip" med 64 kärnor dvs inte så hög frekvens per kärna? ska bli spännande med mer risc-v alternativ för "hemma bruk".

småkollat på en visionfive2 för att börja leka lite med det. borde gå att offra M.2 slotten till en gpu om man kör os från emmc eller sd, alternativt usb3.

andra alternativ typ itx/matx formfaktor kostar skjortan än så länge.

jo det är väl rätt safe att anta att det är linux+wine/proton, vi har väl inte mycket andra OS på risc-v?

En väldigt specifik sak med RISC-V (Om vi jämför med processorer vi normalt sett har i persondatorer ända sedan hemdatorernas tid) är att den inte har några status-flaggor. Normalt när en CPU kör instruktioner sätts t.ex zero flaggan vid en subtraction som resultertar i 0 eller carry-flaggan om en addition inte kan lagras i resulterande register. Detta används väldigt mycket, vid varje conditional branch. RISC-V hanterar detta med lite andra instruktioner, vilket man kan tänka sig ger komplexitet i ett översättningslager.

Sen att RISC-V har 47 instruktioner medan X86 har över 1500 gör också att RISC-V knappast är lika kompakt, det behöver inte betyda att det är sämmre dock.

Dom valde att inte ha med statusflaggor för RISC-V för att den skulle bli enklare att bygga. Statusflaggor är trevliga när man är ute efter prestanda.
RISC-V funkar för om en tillverkare behöver 256bit adds så lägger dom till det i hårdvaran, men när man försöker göra saker hårdvaran inte är byggd för så är RISC-V riktigt dålig.

Tror personligen att RISC-V kommer ta marknad för enklare devices som ARM har idag, eftersom man slipper betala för licensering.

Vi kommer nog till slut få en open source ISA att köra på våra desktops, men kan inte se att det blir RISC-V.

5500XT är ju inget monster till ett grafikkort heller, men viktigast av allt - vi har ingen aning om vilken upplösning eller inställningar man kör på. En snabbgoogling visar att 5500XT precis klarade 60 fps vid 1080p, åtminstone i medel.

Skälet till att de skippade statusflaggorna är nästan säkert att det är lättare att parallellisera och flytta om instruktioner om man inte har dem. Intel lägger till samma möjlighet till med APX av det skälet.

Om inte annat lär det ju finnas enorm potential för optimering om engagemanget och resurserna läggs dvs

Intressant, har du någon bra länk? Inte kollat jättenoga trodde dom skulle dubblera generial purpose register och lägga till flera conditional instruktioner (som kollar flaggor liknande CMOV)

Att Intel lägger till möjligheten att ta bort statusflaggorna?

https://www.intel.com/content/www/us/en/developer/articles/te...

Tredje paragrafen från slutet.

Att det hjälper parallellisering står inte där, men i all enkelhet handlar det om att alla instruktioner som påverkar CC-flaggorna måste exekveras i ordning. Om en instruktion som påverkar CC väntar på data från cachen, så måste alla andra instruktioner som också påverkar CC vänta även om de i övrigt använder helt olika register. Det är nog viktigt att ha den möjligheten om man skall få ut maximalt av att dubbla antalet register.

Jag blir lite nyfiken på varför man inte ser fler sådana här nyheter för Arm64? Snapdragon X har väl en M.2 anslutning där man med lite vilja hade kunnat koppla in en GPU?

vad jag vet är det en av de få generation AMD kort man fått att fungera på arkitekturer utanför x86(_64), såsom ARM64 och risc-v.

Jo, jag förstår att det är en annan sak, och det är en intressant utveckling. Men har du något exempel där man kör ett AAA-spel, med en dGPU, på en högpresterande Arm64-processor så som Snapdragon X Elite?

Inget specifikt exempel, men t.ex. Nvidia har haft ARM64-drivrutiner för Linux sen många år tillbaka. Och t.ex. Ampere Computing har en guide för hur man kör Steam på deras Altra-plattform.

Att det är diskret GPU är ju en smaksak. Tegra X1, dvs Nintendo Switch är ARM + PCIe-kopplad GPU. (jag hade fel, se längre ner).
Ärligt talat är ju alla GPU:er numera PCIe kopplade så skillnaden på att det är en kontakt eller inbyggt i kislet är noll.

Intressant länk, tack!

Jag sa kraftfull

Och det var såklart inte PCIe i sig som var det intressanta, utan en diskret, utbytbar, GPU. Det ska bli väldigt intressant att se när det dyker upp en plattform med högpresterande Arm64-kärnor och PCIe-kontakter, som är rimligt tillgänglig för vanliga konsumenter. Ampere Altra är spännande, men priserna är det inte.

iGPU i Tegra (nog i de flesta designer med iGPU) använder inte PCIe, det vore lite som att gå över ån för att hämta vatten.

Den använder en kombination av NVIDIA Coherent Interconnect (NCI) och AXI (Advanced eXtensible Interface).

Kom på att jag faktiskt har en NVIDIA Jetson TX1 liggande. Där finns PCIe (tror det är 4x PCIe 2.0). Får man tråkigt vore det intressant att stoppa dit en dGPU och ser om det fungerar... Har ett GTX 970 liggade och Nvidias Linux-drivers har sedan länge haft stöd för ARM64.

Okej, jag har faktiskt inte koll på hur en AXI-enhet enumreras i hårdvarulistan i datorn när man interfacear direkt från OS, men misstänker att det inte är någon större skillnad. Lär väl dyka upp som en minnesadress och som man får skriva sin drivrutin till.

AXI till PCIe bryggor är ju inget konstigt att använda och närmast transparent när man väl klurat till alla BARs och översättningar mellan adressrymderna.

Det sagt:
ARM + PCIe, inget nytt.
ARM + Spel, inget nytt.

Modern ARM (inte Cortex-A57 eller dyl) + extern GPU via PCIe + AAA spel. Inte nytt, men jag hittar verkligen inte många exempel när jag söker.

Jag tror inte den är flaskhalsen, har ett 5500 xt hemma och vill minnas att den är rätt kapabel.
https://youtu.be/IEa6FOl87oY ca 50fps average enligt video här.
https://youtu.be/vXEbRv69lPI 40fps på ultra med intel 4770 cpu dessutom.

Frustrationen var mest för att x86-64 är lite speciell, med 8-bittars register på bittarna 15-8 inuti ett 64-bittarsregister.

Assembler-hackare på Reddit tog genast sig an problemet och fick ner det till fyra rader kod.

Kärnan som det är 64 av, T-Head C920 är egentligen lite gammal, och saknar nyare instruktioner som skulle göra det mesta snabbare. Dessutom stödjer den inte den officiella versionen av vektor-utökningen, så alla SSE-instruktioner har fått emuleras ett element i taget.