For flere dage siden resultaterne af et eksperiment blev afsløret af organisation baseret på lanceringen af Linux-kerne i virtuelt 3D-rum af et online multiplayer-spil.
Dette eksperiment Det blev gjort på VRChat, som giver dig mulighed for at indlæse 3D-modeller med dine egne shaders. For at implementere den udtænkte idé blev der skabt en emulator baseret på RISC-V-arkitekturen, som udføres på GPU-siden i form af en pixel shader.
Om projektet
Emulatoren er baseret på C-sprogimplementeringen, hvis skabelse til gengæld brugte udviklingen af den minimalistiske riscv-rust-emulator, som igen er udviklet i Rust-sproget. Den forberedte C-kode er oversat til en pixel shader på HLSL-sproget, velegnet til upload til VRChat.
Emulatoren giver fuld support til rv32imasu instruktionssæt-arkitekturen, SV32 hukommelseskontrolenheden og et minimalt sæt periferiudstyr (UART og timer). De færdiglavede muligheder er nok til at indlæse Linux 5.13.5-kernen og det grundlæggende BusyBox-kommandolinjemiljø, som du kan interagere med direkte fra den virtuelle VRChat-verden.
Omkring marts 2021 besluttede jeg at skrive en emulator, der er i stand til at køre en fuld Linux-kerne på VRChat. På grund af platformens iboende begrænsninger måtte det valgte værktøj være en skygge. Og efter et par måneders arbejde er jeg nu stolt over at kunne præsentere verdens første RISC-V SoC/CPU-emulator (såvidt jeg ved) i en HLSL pixel shader, der er i stand til at køre op til 250kHz (på en 2080 Ti) og starte Linux 5.13.5 med MMU-understøttelse.
Emulatoren er implementeret i shaderen i form af sin egen dynamiske tekstur (Unity Custom Render Texture), suppleret med de medfølgende Udon-scripts til VRChat, som bruges til at styre emulatoren under kørsel.
Indholdet af hovedhukommelsen og tilstanden af den emulerede systemprocessor gemmes som en tekstur med en størrelse på 2048×2048 pixels, således kører den emulerede processor ved 250 kHz. Udover Linux kan Micropython også køres på emulatoren.
For at køre Linux troede jeg, at vi skulle bruge mindst 32 MiB hovedhukommelse (RAM), men lad os være sikre og gå efter 64 - ydelsesforskellen vil ikke være stor, og der burde være masser af VRAM.
Til at begynde med var den største præstationsbekymring clockhastighed. Det vil sige hvor mange CPU-cyklusser, der kan køres på en boks.
At organisere datalagring vedholdende med støtte til læsning og skrivning, der bruges et trick relateret til at bruge et kameraobjekt bundet til et rektangulært område genereret af shaderen og dirigerer outputtet af den gengivne tekstur til input af shaderen. Derfor, enhver pixel skrevet under udførelsen af en pixel shader kan læses, når den næste frame behandles.
Når der anvendes pixelskyggere, lanceres en separat forekomst af skyggeren parallelt for hver pixel i teksturen.
Denne funktion komplicerer implementeringen betydeligt og kræver en separat koordinering af tilstanden af hele det emulerede system og sammenligningen af positionen af den behandlede pixel med tilstanden af CPU'en eller indholdet af RAM'en i det emulerede system kodet i den (hver pixel kan kode 128 bit information).
I dette tilfælde kræver shader-koden medtagelsen af et stort antal kontroller for at forenkle implementeringen af hvilken perl-forprocessoren perlpp blev brugt.
For dem der er interesseret i specifikationerne det nævnes at:
- koden er på github
- 64 MiB RAM minus CPU-tilstand er lagret i en 2048×2048 pixel (128 bpp) heltalsformattekstur
- Unity brugerdefineret gengivelse tekstur med buffer swapping tillader encode/decode tilstand mellem frames
- en pixel shader bruges til emulering, da UAV og compute shaders ikke understøttes af VRChat
Endelig hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne I det følgende link.