Several days ago the results of an experiment were released organization based on the launch of the Linux kernel within 3D virtual space of an online multiplayer game.
This experiment It was done on VRChat which allows loading 3D models with their own shaders. To implement the conceived idea, an emulator based on the RISC-V architecture was created which is executed on the GPU side in the form of a pixel shader.
About the project
The emulator is based on the implementation in the C language, whose creation, in turn, used the developments of the minimalist riscv-rust emulator, which in turn is developed in the Rust language. The prepared C code is translated into a pixel shader in the HLSL language, suitable for loading into VRChat.
The emulator provides full support for the rv32imasu instruction set architecture, the SV32 memory control unit and a minimal set of peripherals (UART and timer). The ready-made capabilities are sufficient to load the Linux kernel 5.13.5 and the basic BusyBox command-line environment, with which you can interact directly from the virtual world of VRChat.
Around March 2021, I decided to write an emulator capable of running a full Linux kernel in VRChat. Due to the inherent limitations of that platform, the chosen tool had to be a shader. And after a few months of work I'm now proud to introduce the world's first RISC-V CPU / SoC emulator (that I know of) in an HLSL pixel shader, capable of running up to 250 kHz (on a 2080 Ti) and boot Linux 5.13.5 with MMU support.
The emulator is implemented in the shader in the form of its own dynamic texture (Unity Custom Render Texture), supplemented by the Udon scripts provided for VRChat, which are used to control the emulator at runtime.
The main memory content and the processor state of the emulated system are saved as a texture with a size of 2048 × 2048 pixels, thereby operating the emulated processor at 250 kHz. Besides Linux, Micropython can also be run on the emulator.
To run Linux I thought we would need at least 32 MiB of main memory (RAM), but let's be safe and make 64 - the performance difference won't be big and there should be enough VRAM.
At first, the main performance concern was clock speed. That is, how many CPU cycles can be executed in one frame.
To organize data storage persistent with support for reading and writing, a trick related to using a Camera object linked to a rectangular area is used generated by the shader and directing the output of the rendered texture to the input of the shader. Therefore, Any pixel written during the execution of a pixel shader can be read by processing the next frame.
When pixel shaders are applied, a separate instance of the shader is fired in parallel for each pixel in the texture.
This feature significantly complicates implementation and requires separate coordination of the state of the entire emulated system and comparison of the position of the processed pixel with the state of the CPU or RAM content of the emulated system encoded in it (each pixel can encode 128 bits of information).
In this case, the shader code requires the inclusion of a large number of checks, to simplify the implementation of which the perl preprocessor perlpp was used.
For those who are interested in the specs it is mentioned that:
- the code is on GitHub
- 64 MiB of RAM minus CPU state is stored in a 2048 × 2048 pixel (128 bpp) integer format texture
- Unity custom render texture with buffer swapping allows encoding / decoding state between frames
- a pixel shader is used for emulation as compute and UAV shaders are not supported by VRChat
Finally if you are interested in knowing more about it, you can check the details In the following link.