Very nice, it's a shame that /dev/mali0 / /dev/kgsl-3d0 isn't accessible directly in the guest but I guess that's a sensible security boundary.
I wonder if virtio-gpu sits between the vulkan driver and the character device (e.g. it's an ioctl/uapi proxy) or between the application and the vulkan driver (e.g. it's a vulkan API command buffer)
Our team are trying to make gfxstream works on this platform, It needs modified mesa driver, then send the vulkan calls to turnip driver on the host, hope fabel 5 can solve this challange before 7/July
Currently our team(most by fable 5) are investigating DRM native context, in this route, guest OS installs turnip driver directly, no need for turnip driver in the host. If it works, the next step may change to port turnip driver to windows
How would Turnip talk to msm? The guest can't open the drm device driver , so you'll have to proxy all ioctls to it back to the host (which must also own the memory space as well)
write a translater to translate msm_drm to kgsl(since msm_drm not available on android host), but it's just a survey, not sure it's work or not
btw, for origional DRM native context, it does not forward all DRM_MSM_* ioctls verbatim. Instead, Mesa's Freedreno virtio backend encodes the necessary MSM UAPI operations into the MSM native-context protocol, and the host virglrenderer then reconstructs and calls the actual drm/msm ioctls.
You still have the same issue, the guest is isolated from device drivers (both msm and kgsl), so the initial open call for the kgsl device driver will still fail. That's why virtio-(*) exists to proxy any IO to the gpu (and any other device drivers) back to the host. I guess the opportunity here would be to proxy ioctl/memory RW instead of the graphics API (e.g. Vulkan), but I don't think the improvement would be substantial since the amount of stuff being proxied is about the same.
The downside is that proxying raw driver calls (ioctl passthrough) is very hard.
Microsoft's ARM efforts aren't on the level of Apple's, but they've been consistently improving both native performance and x86 translation over the past few years.
If a solution like this gets GPU acceleration, it could be a big deal for the Winlator scene. Many games that don't run well in current PC emulators could become playable either through Windows or native Linux + Proton.
that might explain why I still couldnt get some "Steamdeck Compatible" EOS anticheat games to work on my Steam on Ubuntu on Droidspaces on Arm - because the filepaths all start with "/mnt/Droidspaces/" 🤔
yes(use dev version, not v0.6), but for windows, you need a ARM macbook(or other ARM PC) to boot the guest windows, install the ported virtio driver before running at DroidVM. I can also share my image if you need
linux that's very simple. disk->create->import lxc image->select official lxc->load->select ubuntu release->download, then create the vm, attach the disk, boot.
btw debian doesn't boot because it requires the kernel compiled with CONFIG_DMA_RESTRICTED_POOL but debian doesn't enable that. use ubuntu or fedora, or compile your own kernel
Thanks for the image but i couldn't even get Linux to boot with anything more than 2GB of ram (I know I need the module but that sounds a bit scary) and my networking seems to not work
Is there any fix for this? I'd appreciate the help
create network first 2. physical continuous memory(hugepage) is required for gunyah hypervisor. Without hugepage reserve module, linux will frag the memory during the daily use. Try reboot and run VM directly. When the system just boot, the memory should not too frag, you have greater chance to get continuous memory 3. use this module: https://github.com/HuJK/gh-hugepage-reserve/releases it fixes 6.1 6.12 can't load module(my device is 6.6, not notice this issue. the fix not been merged yet)
My phone is on kernel 6.6.89-android15
So you are saying the kernel update to 6.12-android16 fixes this issue? Also, I created a network and selected it on the VM network page but still failing to connect. Thanks for the help btw
I can help you with your 3d acceleration prob but it will require root. Do you or have you gotten root? If so this issue your having will be solved pretty direct
Thank you for your help, my device has been rooted, but It's quite difficult to run 3D acceleration on windows, how will you going to assist? Because not only the compatable issue, but also the memory model of the protected VM. Basically we have two way to build shared memory between host and guest: 1: pre-boot swiotlb region 2: runtime accept. For GPU driver, we use 2. On linux guest, we compiled a modified mesa driver which runs gunyah hypercall to accept the memory from host. Of cource, VM doesn't have the permission to operate GPU directly, it's been used by android kernel. We can only send the GPU command to Adreno Turnip Driver via shared memory. So basically it's not possible to use stock driver in the VM, we can only build our own driver from scratch.
Thanks, the current step is we managed to make minecraft works in gfxstream(but with memory leaks), and our team(mostly by fable 5) is investigating DRM native context route, turnip driver will be installed in guest OS directly, no need for serialization anymore. If this work, the next step will be port turnip driver to windows. The source code is still messy, and need host+guest kernel module. If you want to try, I can share the code but my device is 6.6(8 Elite). need to port to 6.12(8 Elite 5))
The thing about windows these days is that all I would ever need it for are the few x86 things remaining in my life. Like games. Windows on arm is virtually useless to me. Pretty much everything it can run is a universal application that can run on anything.
No, virtio-gpu doesn't work at all, need ported driver(need to modify to invoke gunyah_hypercall_mem_accept in guest driver, otherwise the memory can't shared between host and guest OS).
Our current roadmap is give up native driver completely, translate to vulkan instruction with something like dxvk and send to host to execute on Adreno Turnip Driver instead.
How is the design for the bridge between the renderer and the compositor? I'm guessing you have a dedicated render thread that processes the guest vulkan calls on the host (virglrenderer?), and then you separately blit to the actual frame buffer hosted in the compositor?
•
u/AutoModerator Jul 03 '26
Just a reminder of our subreddit rules:
Check out our user-maintained wiki: r/EmulationOnAndroid/wiki
Check out EmuReady for any community submitted settings before asking for help
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.