drm/virtio: not pin pages on demand
Chia-I Wu
olvaffe at gmail.com
Thu Oct 21 16:42:00 UTC 2021
On Thu, Oct 21, 2021 at 4:52 AM Gerd Hoffmann <kraxel at redhat.com> 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.
>
> take care,
> Gerd
>
More information about the dri-devel
mailing list