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.wezdecki@xxxxxxxxxxxxxxx> 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 spaceWhen you never need cpu access to your gpu object there is no need to create a resource in the first place. take care, Gerd
