I get your point. However, we need to make resource_create ioctl, in order to create corresponding resource on the host.
The concept is: App | Gallium | Guest kernel What is happening? init() ... ... glTexImage2d: [PIPE_DISCARD_WHOLE_RESOURCE] -> resource_create() -> DRM_IOCTL_VIRTGPU_RESOURCE_CREATE -> virtio_gpu_object_create(): -> drm_gem_shmem_create() [allocation of bo#1] -> virtio_gpu_smd_resource_create_3d [sending cmd to crosvm/qemu to create GL object] -> texture_map() [staging buffer is selected] -> memcpy() [memcpy from user's mem to staging buffer] -> texture_unmap() [VIRGL_CCMD_COPY_TRANSFER3D with staging buffer] Selecting staging buffer for texture uploads from guest to host and not pinning resources in DRM_IOCTL_VIRTGPU_RESOURCE_CREATE can save a lot of RAM. With previous approach we always create resource, we upload from guest to host and we never unpin pages, which causes high RAM usage by the guest. With proposed approach, we create resource, we decide that for textures we won't pin pages, we select staging buffer (which is recycled then) for uploads. This causes lower memory consumption. With best regards, Maksym On 10/21/21 11:25 AM, Gerd Hoffmann wrote: > On Thu, Oct 21, 2021 at 09:44:45AM +0200, Maksym Wezdecki wrote: >> From: mwezdeck <maksym.wezde...@collabora.co.uk> >> >> The idea behind the commit: >> 1. when resource is created, let user space decide >> if resource should be pinned or not >> 2. transfer_*_host needs pinned memory. If it is not >> pinned, then pin it. >> 3. during execbuffer, decide which bo handles should >> be pinned based on the list provided by user space > When you never need cpu access to your gpu object there is > no need to create a resource in the first place. > > take care, > Gerd >