För flera dagar sedan resultaten från ett experiment släpptes organisation baserad på lanseringen av Linux -kärna inom 3D virtuellt utrymme av ett online multiplayer -spel.
Detta experiment Det gjordes på VRChat som gör det möjligt att ladda 3D -modeller med sina egna shaders. För att implementera den tänkta idén skapades en emulator baserad på RISC-V-arkitekturen som körs på GPU-sidan i form av en pixelskuggare.
Om projektet
Emulatorn är baserad på implementeringen på C -språket, vars skapande i sin tur använde utvecklingen av den minimalistiska riscv-rostemulatorn, som i sin tur är utvecklad på Rust-språket. Den förberedda C -koden översätts till en pixelskuggare på HLSL -språket, lämplig för laddning i VRChat.
Emulatorn ger fullt stöd för rv32imasu -instruktionsuppsättningsarkitekturen, minneskontrollenhet SV32 och en minimal uppsättning kringutrustning (UART och timer). Förberedda funktioner är tillräckliga för att ladda Linux -kärnan 5.13.5 och BusyBox grundläggande kommandoradsmiljö, med vilken du kan interagera direkt från VRChat virtuella värld.
Runt mars 2021 bestämde jag mig för att skriva en emulator som kan köra en fullständig Linux -kärna i VRChat. På grund av plattformens inneboende begränsningar måste det valda verktyget vara en skuggare. Och efter några månaders arbete är jag nu stolt över att kunna presentera världens första RISC-V CPU / SoC-emulator (som jag känner till) i en HLSL-pixelskuggare, som kan köra upp till 250 kHz (på en 2080 Ti) och starta Linux 5.13.5 med MMU -stöd.
Emulatorn implementeras i skuggaren i form av sin egen dynamiska struktur (Unity Custom Render Texture), kompletterad med Udon -skript som tillhandahålls för VRChat, som används för att styra emulatorn vid körning.
Huvudminnesinnehållet och processortillståndet för det emulerade systemet sparas som en textur med en storlek på 2048 × 2048 pixlar, och driver därigenom den emulerade processorn vid 250 kHz. Förutom Linux kan Micropython också köras på emulatorn.
För att köra Linux trodde jag att vi skulle behöva minst 32 MiB huvudminne (RAM), men låt oss vara säkra och göra 64 - prestandaskillnaden blir inte stor och det borde finnas tillräckligt med VRAM.
Till en början var det viktigaste prestandaproblemet klockhastighet. Det vill säga hur många CPU -cykler som kan köras i en ram.
För att organisera datalagring ihållande med stöd för läsning och skrivning, ett trick relaterat till att använda ett kameraobjekt kopplat till ett rektangulärt område används genereras av skuggaren och riktar utsignalen från den återgivna texturen till skuggarens ingång. Därför, Alla pixlar som skrivs under körningen av en pixelskuggare kan läsas genom att bearbeta nästa bildruta.
När pixelskuggare tillämpas avfyras en separat instans av skuggaren parallellt för varje pixel i texturen.
Denna funktion komplicerar avsevärt implementeringen och kräver separat samordning av tillståndet för hela det emulerade systemet och jämförelse av positionen för den bearbetade pixeln med tillståndet för CPU eller RAM -innehållet i det emulerade systemet som är kodat i det (varje pixel kan koda 128 bitar av information).
I detta fall kräver shader -koden att ett stort antal kontroller inkluderas för att förenkla implementeringen av vilken perl preprocessor perlpp användes.
För dem som är intresserad av specifikationerna det nämns att:
- koden finns på GitHub
- 64 MiB RAM -minne CPU -tillstånd lagras i ett 2048 × 2048 pixel (128 bpp) heltalformatstruktur
- Enhet anpassad renderstruktur med buffertbyte tillåter kodning / avkodningstillstånd mellan ramar
- en pixelskuggare används för emulering som beräkning och UAV -skuggare stöds inte av VRChat
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna I följande länk.