For flere dager siden resultatene av et eksperiment ble offentliggjort organisasjon basert på lanseringen av Linux -kjerne i 3D virtuelt rom av et online flerspillerspill.
Dette eksperimentet Det ble gjort på VRChat som tillater lasting av 3D -modeller med sine egne shaders. For å implementere den oppfatte ideen ble det opprettet en emulator basert på RISC-V-arkitekturen som kjøres på GPU-siden i form av en pikselskygge.
Om prosjektet
Emulatoren er basert på implementeringen på C -språket, hvis skapelse på sin side brukte utviklingen av den minimalistiske riscv-rust-emulatoren, som igjen er utviklet på Rust-språket. Den forberedte C -koden blir oversatt til en pixel shader på HLSL -språket, egnet for lasting i VRChat.
Emulatoren gir full støtte for rv32imasu -instruksjonsarkitekturen, SV32 minnekontrollenhet og et minimalt sett med eksterne enheter (UART og timer). Forberedte evner er tilstrekkelig til å laste Linux -kjernen 5.13.5 og BusyBox grunnleggende kommandolinjemiljø, som du kan samhandle direkte fra VRChat virtuelle verden.
Rundt mars 2021 bestemte jeg meg for å skrive en emulator som kunne kjøre en full Linux -kjerne i VRChat. På grunn av de iboende begrensningene til den plattformen, måtte det valgte verktøyet være en skygge. Og etter noen måneders arbeid er jeg nå stolt over å introdusere verdens første RISC-V CPU / SoC-emulator (som jeg vet om) i en HLSL pixel shader, som kan kjøre opptil 250 kHz (på en 2080 Ti) og starte Linux 5.13.5 med MMU -støtte.
Emulatoren implementeres i skyggeleggeren i form av sin egen dynamiske tekstur (Unity Custom Render Texture), supplert med Udon -skriptene som er gitt for VRChat, som brukes til å kontrollere emulatoren under kjøretid.
Hovedminnet og prosessortilstanden til det emulerte systemet lagres som en tekstur med en størrelse på 2048 × 2048 piksler, og derved drives den emulerte prosessoren ved 250 kHz. I tillegg til Linux kan Micropython også kjøres på emulatoren.
For å kjøre Linux trodde jeg at vi ville trenge minst 32 MiB hovedminne (RAM), men la oss være trygge og tjene 64 - ytelsesforskjellen vil ikke være stor og det bør være nok VRAM.
Først var det viktigste ytelsesproblemet klokkehastighet. Det vil si hvor mange CPU -sykluser som kan utføres i en ramme.
Å organisere datalagring vedvarende med støtte for lesing og skriving, et triks knyttet til bruk av et kameraobjekt knyttet til et rektangulært område brukes generert av skyggeleggeren og lede utgangen fra den gjengitte teksturen til inngangen til skyggeleggeren. Derfor, Enhver piksel skrevet under utførelsen av en pikselskygge kan leses ved å behandle den neste rammen.
Når pikselskygger brukes, avfyres en egen forekomst av skyggen parallelt for hver piksel i teksturen.
Denne funksjonen kompliserer implementeringen betydelig og krever separat koordinering av tilstanden til hele det emulerte systemet og sammenligning av posisjonen til den behandlede pikslen med tilstanden til CPU eller RAM -innholdet i det emulerte systemet som er kodet i det (hver piksel kan kode for 128 bits med informasjon).
I dette tilfellet krever shader -koden inkludering av et stort antall sjekker, for å forenkle implementeringen som perl preprocessor perlpp ble brukt.
For de som er interessert i spesifikasjonene det nevnes at:
- koden er på GitHub
- 64 MiB RAM minus CPU -tilstand lagres i en 2048 × 2048 piksler (128 bpp) tekstur i heltallformat
- Enhetens tilpassede gjengivelsesstruktur med bufferbytte tillater koding / dekodingstilstand mellom rammer
- en pixel shader brukes til emulering som beregning, og UAV -shaders støttes ikke av VRChat
Endelig hvis du er interessert i å vite mer om det, kan du sjekke detaljene I den følgende lenken.