On Wed, May 6, 2020 at 12:14 AM Gerd Hoffmann <> wrote:
 Hi,
> > > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > > or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> > > explicit API level. That way, the blob id is only allowed with HOST3D.
> >
> > I think we can also simply define "blob id is only allowed virgl=on", no
> > need for a separate command.
> >
>
> Ack. Chia's suggestion to possibly only allow GUEST for dumb blobs is also
> reasonable (i.e, no host allocations -- RESOURCE_{MAP, UNMAP}_BLOB are 3D
> only).
Yes, that works too.
> What do you prefer?
I don't mind much.
> > > Ack. I definitely see the logic behind VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
> > > but current display integration (dpy_gl_scanout_texture(..) in QEMU)
> > > assumes the presence of a GL texture (which can be created from a blob
> > > resource).
> >
> > I have a qemu VIRTIO_GPU_CMD_SET_SCANOUT_BLOB implementation for
> > virgl=off only, covering dumb bo / fbdev as outlined above.
>
> Will add VIRTIO_GPU_CMD_SET_SCANOUT_BLOB in v2. Do you also want
> SCANOUT_FLUSH too?
I think we need that, RESOURCE_FLUSH isn't going to work for resources
without an format attached.
Okay, added. SCANOUT_BLOB is based on QemuDmaBuf, but left out the modifier since that can be queried from virglrenderer. LMK if anything else is needed...
Â
take care,
 Gerd
