VirGL + Virtio GPU support for GPU accel

[ZLangJIT]

how might i go about implementing GPU acceleration support via rvvm and a custom riscv kernel, specifically

GL INSTANCE - RENDERER - PID 284 - HOST SHELL - RVVM - KERNEL - PID 382 = GUEST

• RVVM is executed as a seperate process so it CANNOT crash the host renderer

as im thinking of something like https://github.com/dmaivel/sharedgl for api remoting from the guest to the host (android EGL host context) tho im not sure how to go about such

most implementations (using qemu) seem to expose shared memory (eg /dev/shm/foo or /dev/ashmem/foo (not sure what win32 equivilant would be) ) from host to guest which can be used for the custom guest driver to communicate with the host remoting server among other purposes

[LekKit]

I think it would be better to invest into a virtio-gpu device implementation and reuse existing virglrenderer on host and Mesa virgl driver in guest.

[ZLangJIT]

I think it would be better to invest into a virtio-gpu device implementation and reuse existing virglrenderer on host and Mesa virgl driver in guest.

would that work on windows OS host as well as unix* hosts ?

hmm https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24223

[ZLangJIT]

ok i managed to get https://gitlab.freedesktop.org/virgl/virglrenderer compiling for the ndk (api 28) in cmake with meson

[ZLangJIT]

https://github.com/ZLangJIT/riscv-kernel/actions/runs/11163610342/job/31030971191

• got the kernel side virgl module compiled
• updated some stuff
• added release build signing (apk)
• added a patch-cache based build system to automate component builds (mainly the buildroot and kernel)
• • • as per its name cache-patch, this is intended to support only single version caching via the latest version - a new version overwrites the old version
• • • • the component cache is expected to have the name patches-<component> where <component> is the component name, eg kernel.patch should be in a release with the patches-kernel release tag and MUST contain the following files - kernel.patch , kernel.patch.latest.major , kernel.patch.latest.minor , kernel.patch.latest.version_code and MAY contain any other files as needed
• • • basically you (optional) edit stuff in the source tree and generate a new patch push a patch (can be same patch as previously pushed) for a source tree and the patch-cache handles the rest (provided it is correctly set up)
• • generates incremental version codes based on source tree modifications and patch comparison as well as a version information string for all components
• • • supports major and minor versioning
• • • • one need only update major version in the case where any signifigant changes should occur in their view (optional)
• • • • • versioning bumps minor when the current patch differs from the last, and resets minor to 0 when current major differs from last major
• • • • • initializes as major 1 , minor 0 , version code 1
• • • • • can produce a summed version code consisting of all components for global versioning (eg a code 1 and b code 2 yields global code 3 , where a and b are seperate components)
• • a rebuild is triggered if the source tree changes in comparison to the last successful build
• • • should a rebuild be required, please delete the corresponding .patch file in the corresponding component cache
• • • shell environmental variables are not considered
• • • • the patch-cache system cannot detect a change from make CC=gcc to make CC=clang unless this change occurs inside the file tree itself (such as inside a build script located in the source tree)
• • • this avoids potentially costly initial setup / build even when ccache is used
• • • it is up to the underlying build system user files (eg, Makefile, CMakeLists.txt, sh, ect) to coordinate with the patch-cache system to correctly cache and download cached prebuilts

[ZLangJIT]

specifically, to clarify the above

• we have virglrenderer compiled for ndk aarch64 in the android host apk
• we have virtio virgl kernel module compiled ([*]) in the rvvm guest kernel
• we have mesa, x11, opengl and egl (and a few test applications) compiled into the guest kernel cpio via buildroot

but i do not know how to make virglrenderer and virgl talk to eachother

[ZLangJIT]

apparently the vm must support a virtio gpu

[ZLangJIT]

hmm

https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h

https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-gl.c

https://developer.ibm.com/articles/l-virtio/ - Virtio Architecture

hmm https://www.intel.com/content/www/us/en/docs/programmable/683140/24-2-12-1-0/virtio.html

[ZLangJIT]

@LekKit how might i go about beginning to port this from qemu over to rvvm ?

[ZLangJIT]

https://gitlab.com/qemu-project/qemu/-/tree/master/hw/virtio oof, lots of files

[ZLangJIT]

hmm https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html appears to be the reference for the HOST implementation of virtio (vm/hyperv/kvm/ect side) and for the CLIENT implementation of virtio (guest/kernel side)

[ZLangJIT]

the only implementation of virt-gpu i can find is qemu's hw/display/virtio*.c

not even the kernel has a virt-gpu implementation, just seems to have a guest implementation even though the kernel has a KVM hypervisor implementation

[ZLangJIT]

hmm https://github.com/sysprog21/semu/pull/34 - implement virtio-gpu + utilize kernel virgl + host virglrenderer

[LekKit]

I hope they won't be mad if we look at their implementation and reuse it somewhat :)

@X547 Could you please look at this whenever you have free time? It seems that GUI backends don't need any changes for this.

[ZLangJIT]

imma move to a new issue

[LekKit]

Nah it's fine here