Jesse Barnes wrote: > On Mon, 17 Aug 2009 22:22:34 +0200 > Thomas Hellström <tho...@shipmail.org> wrote: > > >> Kristian Høgsberg wrote: >> >>> This patch adds a vblank synced pageflip ioctl for to the >>> modesetting family of ioctls. The ioctl takes a crtc and an fb and >>> schedules a pageflip to the new fb at the next coming vertical >>> blank event. This feature lets userspace implement tear-free >>> updating of the screen contents with hw-guaranteed low latency page >>> flipping. >>> >>> The ioctl is asynchronous in that it returns immediately and then >>> later notifies the client by making an event available for reading >>> on the drm fd. This lets applications add the drm fd to their main >>> loop and handle other tasks while waiting for the flip to happen. >>> The event includes the time of the flip, the frame counter and a 64 >>> bit opaque token provided by user space in the ioctl. >>> >>> Based on work and suggestions from >>> Jesse Barnes <jbar...@virtuousgeek.org>, >>> Jakob Bornecrantz <wallbra...@gmail.com>, >>> Chris Wilson <ch...@chris-wilson.co.uk> >>> >>> Signed-off-by: Kristian Høgsberg <k...@redhat.com> >>> Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org> >>> --- >>> >>> Ok, another version of this patch. This one has fixes to work with >>> radeon kms plus a missing list head init that would cause an oops >>> in the case where we schedule a flip before the previous one has >>> been queued. >>> >>> I'm now ready to propose this patch for the 2.6.32 merge window. >>> >>> >>> >> Hi! >> First a general question: There is some hardware (for example >> Unichromes and Chrome9) that can schedule >> page-flips in the command stream after optional vblank barriers. For >> this kind of hardware the pageflip would be a matter of scheduling >> the flip and fence the old and new buffers. No need for delayed >> unpins and explicit user-space notifications, although the workqueue >> could be handy to avoid command processing stalls in the vblank >> barriers. How would such a scheme fit into the framework below? >> > > If you fence the flip, doesn't that mean you only unpin after it's > completed? The initial version of this patch used a command stream > flip, but I still had to worry about pinning... > With a fenced flip (and some TTM terminology) it would amount to
reserve(old_scanout); // Reserve means "claim buffer for validation". reserve(new_scanout); submit_flip(); unpin(old_scanout); pin(new_scanout); fence(both_scanouts); unreserve(old_scanout); unreserve(new_scanout); So the pin / unpin would happen at command submission time and not at flip execution time, and the fence would make sure any old scanouts remain in GPU memory until they are no longer referenced by the VDC. But the real benefit of this scheme is pageflipping without vblank waits. I'm not sure the vblank barrier stalls are acceptable in reality, since they block all command execution. > If you don't need the userspace notifications we could probably factor > that out; do you see any issues with the flip ioctl itself? If not, we > can change things as needed if/when more drivers support it... > > No, I don't have anything against it at all. I'm just trying to get a basic understanding how this would be implemented with different hardware, and as you say, we could change things if needed if the need for it arises. /Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
