Once again with all lists and receivers. I'm sorry for that.
On 10/21/21 6:42 PM, Chia-I Wu wrote:
On Thu, Oct 21, 2021 at 4:52 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:On Thu, Oct 21, 2021 at 11:55:47AM +0200, Maksym Wezdecki wrote:I get your point. However, we need to make resource_create ioctl, in order to create corresponding resource on the host.That used to be the case but isn't true any more with the new blob resources. virglrenderer allows to create gpu objects via execbuffer. Those gpu objects can be linked to a virtio-gpu resources, but it's optional. In your case you would do that only for your staging buffer. The other textures (which you fill with a host-side copy from the staging buffer) do not need a virtio-gpu resource in the first place.That's however a breaking change to the virgl protocol. All virgl commands expect res ids rather than blob ids. Using VIRTGPU_BLOB_MEM_HOST3D could in theory work. But there are a few occasions where virglrenderer expects there to be guest storage. There are also readbacks that we need to support. We might end up using VIRTGPU_BLOB_MEM_HOST3D_GUEST, where pin-on-demand is still desirable. For this patch, I think the uapi change can be simplified. It can be a new param plus a new field in drm_virtgpu_execbuffer __u64 bo_flags; /* pointer to an array of size num_bo_handles, or NULL */ The other changes do not seem needed.
My first approach was the same, as you mentioned. However, having "__u64 bo_flags" needs a for loop, where only few of the bo-s needs to be pinned - this has performance implications. I would rather pass bo handles that should be pinned than having a lot of flags, where only 1-2 bos needs to be pinned.
take care, Gerd
