qemu/hw/display/virtio-vga-rutabaga.c

51 lines
1.3 KiB
C
Raw Normal View History

gfxstream + rutabaga: add initial support for gfxstream This adds initial support for gfxstream and cross-domain. Both features rely on virtio-gpu blob resources and context types, which are also implemented in this patch. gfxstream has a long and illustrious history in Android graphics paravirtualization. It has been powering graphics in the Android Studio Emulator for more than a decade, which is the main developer platform. Originally conceived by Jesse Hall, it was first known as "EmuGL" [a]. The key design characteristic was a 1:1 threading model and auto-generation, which fit nicely with the OpenGLES spec. It also allowed easy layering with ANGLE on the host, which provides the GLES implementations on Windows or MacOS enviroments. gfxstream has traditionally been maintained by a single engineer, and between 2015 to 2021, the goldfish throne passed to Frank Yang. Historians often remark this glorious reign ("pax gfxstreama" is the academic term) was comparable to that of Augustus and both Queen Elizabeths. Just to name a few accomplishments in a resplendent panoply: higher versions of GLES, address space graphics, snapshot support and CTS compliant Vulkan [b]. One major drawback was the use of out-of-tree goldfish drivers. Android engineers didn't know much about DRM/KMS and especially TTM so a simple guest to host pipe was conceived. Luckily, virtio-gpu 3D started to emerge in 2016 due to the work of the Mesa/virglrenderer communities. In 2018, the initial virtio-gpu port of gfxstream was done by Cuttlefish enthusiast Alistair Delva. It was a symbol compatible replacement of virglrenderer [c] and named "AVDVirglrenderer". This implementation forms the basis of the current gfxstream host implementation still in use today. cross-domain support follows a similar arc. Originally conceived by Wayland aficionado David Reveman and crosvm enjoyer Zach Reizner in 2018, it initially relied on the downstream "virtio-wl" device. In 2020 and 2021, virtio-gpu was extended to include blob resources and multiple timelines by yours truly, features gfxstream/cross-domain both require to function correctly. Right now, we stand at the precipice of a truly fantastic possibility: the Android Emulator powered by upstream QEMU and upstream Linux kernel. gfxstream will then be packaged properfully, and app developers can even fix gfxstream bugs on their own if they encounter them. It's been quite the ride, my friends. Where will gfxstream head next, nobody really knows. I wouldn't be surprised if it's around for another decade, maintained by a new generation of Android graphics enthusiasts. Technical details: - Very simple initial display integration: just used Pixman - Largely, 1:1 mapping of virtio-gpu hypercalls to rutabaga function calls Next steps for Android VMs: - The next step would be improving display integration and UI interfaces with the goal of the QEMU upstream graphics being in an emulator release [d]. Next steps for Linux VMs for display virtualization: - For widespread distribution, someone needs to package Sommelier or the wayland-proxy-virtwl [e] ideally into Debian main. In addition, newer versions of the Linux kernel come with DRM_VIRTIO_GPU_KMS option, which allows disabling KMS hypercalls. If anyone cares enough, it'll probably be possible to build a custom VM variant that uses this display virtualization strategy. [a] https://android-review.googlesource.com/c/platform/development/+/34470 [b] https://android-review.googlesource.com/q/topic:%22vulkan-hostconnection-start%22 [c] https://android-review.googlesource.com/c/device/generic/goldfish-opengl/+/761927 [d] https://developer.android.com/studio/releases/emulator [e] https://github.com/talex5/wayland-proxy-virtwl Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Alyssa Ross <hi@alyssa.is> Tested-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
2023-03-21 19:47:29 +03:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
#include "qemu/osdep.h"
#include "hw/pci/pci.h"
#include "hw/qdev-properties.h"
#include "hw/virtio/virtio-gpu.h"
#include "hw/display/vga.h"
#include "qapi/error.h"
#include "qemu/module.h"
#include "virtio-vga.h"
#include "qom/object.h"
#define TYPE_VIRTIO_VGA_RUTABAGA "virtio-vga-rutabaga"
OBJECT_DECLARE_SIMPLE_TYPE(VirtIOVGARutabaga, VIRTIO_VGA_RUTABAGA)
struct VirtIOVGARutabaga {
VirtIOVGABase parent_obj;
VirtIOGPURutabaga vdev;
};
static void virtio_vga_rutabaga_inst_initfn(Object *obj)
{
VirtIOVGARutabaga *dev = VIRTIO_VGA_RUTABAGA(obj);
virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
TYPE_VIRTIO_GPU_RUTABAGA);
VIRTIO_VGA_BASE(dev)->vgpu = VIRTIO_GPU_BASE(&dev->vdev);
}
static VirtioPCIDeviceTypeInfo virtio_vga_rutabaga_info = {
.generic_name = TYPE_VIRTIO_VGA_RUTABAGA,
.parent = TYPE_VIRTIO_VGA_BASE,
.instance_size = sizeof(VirtIOVGARutabaga),
.instance_init = virtio_vga_rutabaga_inst_initfn,
};
module_obj(TYPE_VIRTIO_VGA_RUTABAGA);
module_kconfig(VIRTIO_VGA);
static void virtio_vga_register_types(void)
{
if (have_vga) {
virtio_pci_types_register(&virtio_vga_rutabaga_info);
}
}
type_init(virtio_vga_register_types)
module_dep("hw-display-virtio-vga");