Local Display Direct Flip Feature Discussion

[Zhang, Tina]

> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Wednesday, December 19, 2018 7:26 PM
> To: Zhang, Tina <tina.zhang at intel.com>
> Cc: Tian, Kevin <kevin.tian at intel.com>; Wang, Zhenyu Z
> <zhenyu.z.wang at intel.com>; Wang, Zhi A <zhi.a.wang at intel.com>; He, Min
> <min.he at intel.com>; Yuan, Hang <hang.yuan at intel.com>; Alex Williamson
> <alex.williamson at redhat.com>; Lv, Zhiyuan <zhiyuan.lv at intel.com>; Vetter,
> Daniel <daniel.vetter at intel.com>; intel-gvt-dev <intel-gvt-
> dev at lists.freedesktop.org>; Wang, Hongbo <hongbo.wang at intel.com>
> Subject: Re: Local Display Direct Flip Feature Discussion
> 
>   Hi,
> 
> > > Isn't a framebuffer just a gem object with metadata (fourcc, width,
> > > height, stride, ...) attached?  So I'm wondering how that works in
> > > detail.  What happens on page-flip?  Do you make the framebuffer
> > > reference another gem object then?  Or do you blit the guest display
> > > to the framebuffer?
> > The special DRM framebuffer is transparent to the guest display driver.
> > We just want to use this object to save the guest framebuffer info in
> > host-side.
> 
> Hmm, so this object isn't a normal drm framebuffer.  You are just
> masquerading it as drm framebuffer, so you can assign it to a drm crtc or drm
> plane.
Not so bad actually :-)
Host just wants to use a drm framebuffer to describe the drm framebuffer
attached on a vGPU's plane. And the only special thing is that this host drm
frambuffer has on gem backends, which means host cannot manage the
memory of this drm framebuffer. And it's OK, as the guest does the management.
Besides, generic drm framebuffer was designed to be able to deal with this kind
of situation.

> 
> I'm not convinced this is a good idea.
> 
> It makes sense to allow mapping guest outputs to host outputs.  I think it is
> more useful to handle that at crtc level not plane level, so it'll work for both
> primary and cursor plane.  I think it would be cleaner to introduce new drm
> (generic or i915) APIs for that instead of creating special framebuffer objects
> which behave in non-standard ways.
The APIs solution is one of our options and we have patch for it. The userspace
interface is still under discussion. And here are the three candidates:
1) Through i915 ioctl
2) Through vfio/display ioctl
3) Through GVT-g sys fs or debugfs
And option2 is considered as the preferred one, as this drm framebuffer is related
to the vGPU.

> 
> Alternatively try to tackle the problem in a completely different way.
> Right now qemu will check for display changes using a timer.  We could add
> some page flip notification mechanism (using an eventfd for example) so
> qemu can update the host plane (or notify spice client) instantly instead of
> waiting for the next display refresh timer tick.
We could do that. But the local display direct flip feature doesn't want to involve
the host userspace, considering the performance.

Maybe we can add this mechanism to dma-buf use case.

Thanks.


BR,
Tina
> 
> cheers,
>   Gerd
> 
> PS: will be offline until jan 7th starting dec 21st.
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev