From c3a74e10f9aca32cb9c52652270495e7103d264f Mon Sep 17 00:00:00 2001 From: Chia-I Wu Date: Fri, 28 Jan 2022 08:57:37 -0800 Subject: [PATCH] venus: updates to the doc VIRTGPU_PARAM_CONTEXT_INIT has been upstreamed. Misc updates to reflect the current status. Reviewed-by: Yiwei Zhang Part-of: --- docs/drivers/venus.rst | 61 +++++++++++++++--------------------------- 1 file changed, 21 insertions(+), 40 deletions(-) diff --git a/docs/drivers/venus.rst b/docs/drivers/venus.rst index 72da482b9fd..dd337a05db6 100644 --- a/docs/drivers/venus.rst +++ b/docs/drivers/venus.rst @@ -29,6 +29,8 @@ tested with - RADV 21.1 or later (the host kernel must have ``CONFIG_TRANSPARENT_HUGEPAGE`` disabled because of this `KVM issue `__) +- TURNIP 22.0 or later +- Mali r32p0 or later The Venus driver requires supports for @@ -37,11 +39,12 @@ The Venus driver requires supports for - ``VIRTGPU_PARAM_CROSS_DEVICE`` - ``VIRTGPU_PARAM_CONTEXT_INIT`` -from the virtio-gpu kernel driver, unless vtest is used. Currently, this -means the `context-init -`__ -kernel branch paired with `crosvm -`__. +from the virtio-gpu kernel driver, unless vtest is used. That usually means +the guest kernel should be at least 5.16 or have the parameters back ported, +paired with hypervisors such as `crosvm +`__, or `patched +qemu +`__. vtest ----- @@ -74,25 +77,19 @@ server finds the locally built host driver. Virtio-GPU ---------- -Because the driver requires ``VIRTGPU_PARAM_CONTEXT_INIT`` from the virtio-gpu -kernel driver, one must make sure the guest kernel includes the changes from -the `context-init -`__ -branch. +The driver requires ``VIRTGPU_PARAM_CONTEXT_INIT`` from the virtio-gpu kernel +driver, which was upstreamed in kernel 5.16. -To build crosvm, +crosvm is written in Rust. To build crosvm, make sure Rust has been installed +and .. code-block:: console - $ mkdir crosvm + $ git clone --recurse-submodules \ + https://chromium.googlesource.com/chromiumos/platform/crosvm $ cd crosvm - $ wget https://storage.googleapis.com/git-repo-downloads/repo - $ chmod +x repo - $ ./repo init -g crosvm -u https://chromium.googlesource.com/chromiumos/manifest.git - $ ./repo sync - $ cd src/platform/crosvm $ RUSTFLAGS="-L/out/src" cargo build \ - --features "x virgl_renderer virgl_renderer_next default-no-sandbox" + --features "x wl-dmabuf virgl_renderer virgl_renderer_next default-no-sandbox" Note that crosvm must be built with ``default-no-sandbox`` or started with ``--disable-sandbox`` in this setup. @@ -108,11 +105,11 @@ This is how one might want to start crosvm --host_ip 192.168.0.1 \ --netmask 255.255.255.0 \ --mac 12:34:56:78:9a:bc \ - --rwdisk disk.qcow2 \ + --rwdisk disk.img \ -p root=/dev/vda1 \ -assuming a working system is installed to partition 1 of ``disk.qcow2``. +assuming a working system is installed to partition 1 of ``disk.img``. ``sudo`` or ``CAP_NET_ADMIN`` is needed to set up the TAP network device. Virtio-GPU and Virtio-WL @@ -125,8 +122,7 @@ that should hopefully change over time. For now, the guest kernel must be built from the ``chromeos-5.10`` branch of the `Chrome OS kernel -`__. crosvm -should also be built with ``wl-dmabuf`` feature rather than ``x`` feature. +`__. To build minigbm and to enable minigbm support in virglrenderer, @@ -156,10 +152,6 @@ In the guest, build and start sommelier, the special Wayland compositor, --xwayland-gl-driver-path= \ sleep infinity -sommelier requires ``xdg-shell-unstable-v6`` rather than the stable -``xdg-shell`` from the host compositor. One must make sure the host -compositor still supports the older extension. - Optional Requirements --------------------- @@ -172,14 +164,6 @@ In the future, if virglrenderer's ``virgl_renderer_export_fence`` is supported, the Venus renderer will require ``VK_KHR_external_fence_fd`` with ``VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT`` from the host driver. -A WSI image of the Venus driver is an external image to the host driver. When -the WSI image is transitioned from ``VK_IMAGE_LAYOUT_UNDEFINED`` after image -acquisition, the Venus driver does not request the Venus renderer to perform -an ownership transfer on the external image. It is unclear if the ownership -transfer is required or not. A specification issue has been filed for -clarifications. See the comment before ``vn_cmd_fix_image_memory_barrier`` -for more details. - VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT ----------------------------------- @@ -206,9 +190,6 @@ accesses to the device memory are via the guest mapping, and are assumed to be coherent when the device memory also has ``VK_MEMORY_PROPERTY_HOST_COHERENT_BIT``. -When a ``VkImage`` or a ``VkBuffer`` is created, the Venus renderer does not -know if the image or the buffer will be bound to such a device memory or not. -As a result, the Venus renderer unconditionally chains -``VkExternalMemoryImageCreateInfo`` to ``VkImageCreateInfo`` and chains -``VkExternalMemoryBufferCreateInfo`` to ``VkBufferCreateInfo`` without -checking for the host driver support. +While the Venus renderer can force a ``VkDeviceMemory`` external, it does not +force a ``VkImage`` or a ``VkBuffer`` external. As a result, it can bind an +external device memory to a non-external resource.