HOST VRAM Leak when performs android-x86 window rotation with Virt-GPU

[Eunseok Choi]

I will report something strange thing about host VRAM leakage after anroid-x86 window rotation when it runs with virt-gpu(+ virgl-renderer)

Please watching below video link.

https://www.youtube.com/watch?v=mJIbGZLWF1s&feature=youtu.be

(orginal video file : https://drive.google.com/file/d/1lkdTx_8yTbSVjKXlnxnnk96fWe-w6Mxb/view?usp=sharing)

I don't sure what is the problem...

Here are my tested history
--------------------------------------------------------------------------------------------------
Install android-x86 on I7 desktop PCs with intel UHD GPU - No leak.
Install android-x86 on I7 desktop PCs with NVIDIA GTX GPU series - No leak.
Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak
(HOST CPU - I5, INTEL UHD GPU)
Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak
(HOST CPU - I7, NVIDIA GTX GPU)

COMMON:
In case of NVIDIA GPU : check vram using nvidia-smi
In case of intel UHD GPU : check shared-vram using free cmd

We checked guest android-x86 system down when vram is full after performing many rotation
-------------------------------------------------------------------------------------------

Is it virt-gpu driver's problem?

I hope someone can help me...

Thanks in advance!!

PS

Here are qemu options I used...

-machine type=q35,accel=kvm -cpu host --enable-kvm \
-smp cpus=4,cores=4,threads=1 -m 4096 \
-drive file=ctb0319.qcow2,format=qcow2,if=virtio,aio=threads \
-device virtio-vga,virgl=on \
-device qemu-xhci,id=xhci -device usb-mouse,bus=xhci.0 -device usb-kbd,bus=xhci.0 \
-soundhw hda -display sdl,gl=on -netdev user,id=qemunet0,hostfwd=tcp::4000-:7000,hostfwd=tcp::5555-:5555,hostfwd=tcp::4012-:7012,hostfwd=tcp::4013-:7013 -device virtio-net,netdev=qemunet0 -boot menu=on

[Eunseok Choi (riosnai)]

Here are qemu options I used...

-machine type=q35,accel=kvm -cpu host --enable-kvm \
-smp cpus=4,cores=4,threads=1 -m 4096 \
-drive file=ctb0319.qcow2,format=qcow2,if=virtio,aio=threads \
-device virtio-vga,virgl=on \
-device qemu-xhci,id=xhci -device usb-mouse,bus=xhci.0 -device usb-kbd,bus=xhci.0 \
-soundhw hda -display sdl,gl=on -netdev user,id=qemunet0,hostfwd=tcp::4000-:7000,hostfwd=tcp::5555-:5555,hostfwd=tcp::4012-:7012,hostfwd=tcp::4013-:7013 -device virtio-net,netdev=qemunet0 -boot menu=on

[Thomas Huth (th-huth)]

This is the *upstream* QEMU bug tracker here. If you've got a problem with the android emulator, please report these problems to the android emulator project instead. Thanks.

[Eunseok Choi (riosnai)]

To Thomas Huth,

This is not android problem, qemu or virt-gpu problem,.
-------------------- our test log --------------------------------------
Running android-x86 on I7 bare metal desktop PCs with intel UHD GPU - No leak.
Running android-x86 on QEMU(+virt-gpu, virgl-renderer) - Leak
------------------------------------------------------------------------

Also in case of a guest linux, it also have leak after windows manager rotation.

[Thomas Huth (th-huth)]

Ok, sorry, got that wrong - we sometimes get bug reports about the android emulator (which is a fork of QEMU) here, and at a first glance, your bug report looked like one of these misguided bug tickets, too.

Anyway, please provide some more information: Which version of QEMU are you using? Which operating system are you running in QEMU?

[Eunseok Choi (riosnai)]

I tested many qemu & linux versions....

in case of qemu,
2.12
3.10
3.12
4.0.0
All versions I tested have same problem....

also I tested many versions of linux
ubuntu 18.04 18.10
centos 7
fedora 18 19
rhel

Actually it is not only problem of windows rotation, if home launcher refreshed, vram usage is also up...

I think it related gl related functions...

so I don't sure it is qemu-virt-gpu problem or virt-gpu driver...

That is why I already report this problem to android-x86 devel forum and author of virt-gpu drvier...

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]