Add a new compile-time feature, `gfxstream`, which is included in the default features. The only thing that changes is that we can now build without requiring the `gfxstream_backend` library on compilation time, which helps in cases it is not packaged in a distro, or is not available at a user's build machine. Also update `README.md` with information about the build-time feature. This commit does not change anything other than make gfxstream gpu mode opt-out at build-time. Everything should continue to work the same. Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| LICENSE-APACHE | ||
| LICENSE-BSD-3-Clause | ||
| README.md | ||
| rustfmt.toml | ||
vhost-device-gpu - GPU emulation backend daemon
Synopsis
vhost-device-gpu --socket-path <SOCKET> --gpu-mode <GPU_MODE>
Description
A virtio-gpu device using the vhost-user protocol.
Options
-s, --socket-path <SOCKET> vhost-user Unix domain socket
-g, --gpu-mode <GPU_MODE> [possible values: virgl-renderer, gfxstream]
-h, --help Print help
-V, --version Print version
NOTE: Option -g, --gpu-mode can only accept the gfxstream value if the
crate has been built with the gfxstream feature, which is the default.
Limitations
We are currently only supporting sharing the display output to QEMU through a
socket using the transfer_read operation triggered by
VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D to transfer data from and to virtio-gpu 3D
resources. It'll be nice to have support for directly sharing display output
resource using dmabuf.
This device does not yet support the VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB and VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID features.
Currently this crate requires some necessary bits in order to move the crate out of staging:
- Addition of CLI arguments to specify the exact number of capsets and use a default capset configuration when no capset is specified rather than using hard-coded capset value.
Features
The device leverages the rutabaga_gfx crate to provide rendering with virglrenderer and gfxstream.
gfxstream support is compiled by default, it can be disabled by not building with the gfxstream feature flag, for example:
$ cargo build --no-default-features
With Virglrenderer, Rutabaga translates OpenGL API and Vulkan calls to an intermediate representation and allows for OpenGL acceleration on the host.
With the gfxstream rendering mode, GLES and Vulkan calls are forwarded to the host with minimal modification.
Examples
First start the daemon on the host machine using either of the 2 gpu modes:
virgl-renderergfxstream(if the crate has been compiled with the featuregfxstream)
host# vhost-device-gpu --socket-path /tmp/gpu.socket --gpu-mode virgl-renderer
With QEMU, there are two device front-ends you can use with this device.
You can either use vhost-user-gpu-pci or vhost-user-vga, which also
implements VGA, that allows you to see boot messages before the guest
initializes the GPU. You can also use different display outputs (for example
gtk or dbus).
By default, QEMU also adds another VGA output, use -vga none to make
sure it is disabled.
- Using
vhost-user-gpu-pci
Start QEMU with the following flags:
-chardev socket,id=vgpu,path=/tmp/gpu.socket \
-device vhost-user-gpu-pci,chardev=vgpu,id=vgpu \
-object memory-backend-memfd,share=on,id=mem0,size=4G, \
-machine q35,memory-backend=mem0,accel=kvm \
-display gtk,gl=on,show-cursor=on \
-vga none
- Using
vhost-user-vga
Start QEMU with the following flags:
-chardev socket,id=vgpu,path=/tmp/gpu.socket \
-device vhost-user-vga,chardev=vgpu,id=vgpu \
-object memory-backend-memfd,share=on,id=mem0,size=4G, \
-machine q35,memory-backend=mem0,accel=kvm \
-display gtk,gl=on,show-cursor=on \
-vga none
License
This project is licensed under either of
- Apache License, Version 2.0
- BSD-3-Clause License