On 2019.06.28 07:43:46 +0200, Gerd Hoffmann wrote: > On Fri, Jun 28, 2019 at 11:21:49AM +0800, Zhenyu Wang wrote: > > On 2019.06.27 12:31:33 +0200, Gerd Hoffmann wrote: > > > > > Hi, > > > > > > > > > > > Instead of delivering page flip events, we choose to post display > > > > > > vblank event. Handling page flip events for both primary plane and > > > > > > cursor plane may make user space quite busy, although we have the > > > > > > mask/unmask mechansim for mitigation. Besides, there are some cases > > > > > > that guest app only uses one framebuffer for both drawing and display. > > > > > > In such case, guest OS won't do the plane page flip when the > > > > > > framebuffer is updated, thus the user land won't be notified about the > > > > > updated framebuffer. > > > > > > > > > > What happens when the guest is idle and doesn't draw anything to the > > > > > framebuffer? > > > > The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. > > > > Does it make sense to vfio/display? > > > > > > Getting notified only in case there are actual display updates would be > > > a nice optimization, assuming the hardware is able to do that. If the > > > guest pageflips this is obviously trivial. Not sure this is possible in > > > case the guest renders directly to the frontbuffer. > > > > > > What exactly happens when the guest OS disables the pipe? Is a vblank > > > event delivered at least once? That would be very useful because it > > > will be possible for userspace to stop polling altogether without > > > missing the "guest disabled pipe" event. > > > > > > > It looks like purpose to use vblank here is to replace user space > > polling totally by kernel event? Which just act as display update > > event to replace user space timer to make it query and update > > planes? > > I think it makes sense to design it that way, so userspace will either > use the events (when supported by the driver) or a timer (fallback if > not) but not both. Agree. It's more of a userspace choice. > > > Although in theory vblank is not appropriate for this which > > doesn't align with plane update or possible front buffer rendering at > > all, but looks it's just a compromise e.g not sending event for every > > cursor position change, etc. > > > > I think we need to define semantics for this event properly, e.g user > > space purely depends on this event for display update, the opportunity > > for issuing this event is controlled by driver when it's necessary for > > update, etc. Definitely not named as vblank event or only issue at vblank, > > that need to happen for other plane change too. > > I think it should be "display update notification", i.e. userspace > should check for plane changes and update the display. > > Most events will probably come from vblank (typically plane update are > actually committed at vblank time to avoid tearing, right?). That is an > implementation detail though. > Yeah, vblank should be a good time, although driver might also do optimization e.g checking actual plane change between vblank to see if there's any real change, etc. Also that will depend on driver implementation. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Attachment:
signature.asc
Description: PGP signature
