Kristian Høgsberg wrote: > 2009/8/17 Thomas Hellström <tho...@shipmail.org>: > >> 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? >> > > By sending an event back on the file descriptor we allow users of the > API to wait on the flip to finish in a standard poll or select > mainloop, where it can handle input from other sources while waiting. > If you rely on fences, the application will block when it tries to > access the buffers protected by the fence, and is unable to handle > input from other sources while it's blocking. >
Yes. you're right. How is the flip_finished event typically used by user space? Is it mostly for convenience or is it a must have? > Even with the vsync barrier in the command stream (which intel hw also > supports) you do need to keep the current front buffer pinned for the > remainder of the frame, and then you need notification when the swap > has happened so that you can unpin the old buffer. That would be taken care of by fences (see previous mail), but that's merely a terminology thing. The big difference is that the driver would handle that synchronization as part of command submission. > I'm sure Unichrome > has a command to send an interrupt, which can be queued after the > vsync barrier to run the workqueue and trigger this cleanup as well as > sending the userspace notification. > Actually it hasn't (stupid hardware), so a medium frequency polling scheme needs to be used for most GPU waiting. So the user-space notification would require some additional thoughts but nothing that can't be implemented when 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
