[RFC] Display Refresh Events Delivering Poc Combining Vblanks and Pageflips
Lu, Kechen
kechen.lu at intel.com
Mon Jul 15 07:21:09 UTC 2019
Hi,
> -----Original Message-----
> From: Zhenyu Wang [mailto:zhenyuw at linux.intel.com]
> Sent: Monday, July 15, 2019 11:24 AM
> To: Lu, Kechen <kechen.lu at intel.com>
> Cc: Gerd Hoffmann <kraxel at redhat.com>; intel-gvt-dev at lists.freedesktop.org;
> Zhang, Tina <tina.zhang at intel.com>
> Subject: Re: [RFC] Display Refresh Events Delivering Poc Combining Vblanks and
> Pageflips
>
> On 2019.07.12 10:37:23 +0000, Lu, Kechen wrote:
> > Hi,
> >
> > As the discussions we have before about the vblank and pageflip events
> > shows that these two display event delivering favors have their own
> drawbacks, i.e.
> >
> > 1. vblanks would trigger 60 times per second constantly but sometimes cause
> > extra and unnecessary handling and performance drops if no pageflip
> > happens, though it can avoid overwhelmed events in such cases like moving
> > the cursor frequently causing userspace window manager ui overhead
> > 2. pageflip events only would be embarrassing when happening to a single
> > framebuffer like in Linux textmode console, almost no pageflips are
> > triggered, as a consequence, the userspace does not refresh the display
> > while framebuffer updates, thus user experience drops. Plus, just like the
> > vblanks, if overwhelmed events deliver to userspace, the performance drops
> > as well
> >
> >
> > These days we tried some ways to make tradeoff and take the advantage
> > of the both two favors. To be brief, the basic idea is to deliver
> > display refresh events at the vblank, and we skip some unneccessay
> > vblank events if there is no cursor/primay pageflip happens during
> > this period checking the flip_done_event bitmap. In addition, if we
> > happen to a single framebuffer case, i.e. no pageflip happens in a
> > certain period, we still deliver all vblank events to userspace.
> >
> > To simplify the events delivering, we have only one eventfd
> > responsible for these display refresh events, using partitioned 8 byte
> > eventfd count value to designate different events and up to eight. Here we
> define two events, i.e.
> > console refresh and cursor refresh events and its corresponding
> > increasement value, e.g. for primary(or console) framebuffer refresh
> > events DISPLAY_CON_REFRESH_EVENT, the increased val is in highest one
> > byte. When handling the event, if this byte has value, userspace knows
> > the console refresh events delivered.
>
> Better just say that is primary plane event, userspace won't be necessary to tell
> difference from either console text mode or UI page flip, it'd still use vfio gfx API
> to get refreshed fb then. So this gives userspace hint on which plane to refresh.
>
[Lu, Kechen] Make sense. I'll change back to old ones, so how about DISPLAY_PRI_REFRESH_EVENT and DISPLAY_CUR_REFRESH_EVENT this macro naming to designate which plane refresh happens
> >
> > If after some vblanks there is no pageflip, we would assume current
> > case is single framebuffer and deliver all the vblank events to notify
> > userspace to update. Although we still have some tricks to determine
> > if this single framebuffer has updates and skip ones without update,
> > these tricks such as using checksum or hash to compare the framebuffer
> > content are computing-intensive and consuming much cpu resource when
> > idle. So to single framebuffer case, delivering fully vblank events are great
> tradeoff.
>
> I think vblank cycle is upper bound, but we can use some heuristic method to
> check update between real page flips through command or plane reg change or
> e.g cursor movement, etc. But anyway that's driver implementation details,
> we'd better expose API change to align first.
>
[Lu, Kechen] Agreed. In the current implementation, vblank is literally the upper bound. IMO, the heuristic is supposed to be used at each emulated vblank triggers, and this is exactly the current idea. But the current heuristic only includes two parts, one is that we check if the virtual page flip event happens (i.e. check the flip_done_event bit for primary plane plus cursor plane and we have made patch here for cursor plane) In my tests, it shows that in the double framebuffer or tribble framebuffer case, the primary or cursor page flip in command or programmed SURF reg necessarily means the updates happens, and there is no more updates between two flips. This heuristic skips some vblanks when no multiple fb updates. But, the problems reside in single fb case. There is no plane reg update or command submitted when only single fb, so we first think of using the checksum/hash comparison of fb contents as the heuristic, however it's not a trivial one. Hence, we only have another heuristic to determine if we are in single fb case, if it is, let each emulated vblank as the refresh signal. For the API exposed, to keep things simple, we have one eventfd to deliver all planes refresh events, and partition the counter value of eventfd to designate events.
> >
> > Here is the POC you can have a try, kernel upstream in branch topic/
> > display_event:
> > https://github.com/intel/gvt-linux/tree/topic/display_event ,
> > topic/display_event: https://github.com/intel/Igvtg-qemu/tree/topic/
> > display_event.
> >
>
> Would be easier if you can just send patches for comment.
>
> thanks
>
[Lu, Kechen] Sure. I will send patches directly next time.
Best Regards,
Kechen
> --
> Open Source Technology Center, Intel ltd.
>
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: RE: [RFC] Display Refresh Events Delivering Poc Combining Vblanks and Pageflips
Date: no date
Size: 5535
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20190715/b502e4bb/attachment.mht>
More information about the intel-gvt-dev
mailing list