On 12 nov 2009, at 17.44, Kristian Høgsberg wrote: > This adds a page flipping ioctl to the KMS API. The ioctl takes an > fb ID > and a ctrc ID and flips the crtc to the given fb at the next vblank. > The ioctl returns immediately but the flip doesn't happen until after > any rendering that's currently queued up against the new framebuffer > is done. After submitting a page flip, any execbuffer involving the > old front buffer will block until the flip is completed. > > Optionally, a vblank event can be generated when the swap eventually > happens. > > Signed-off-by: Kristian Høgsberg <[email protected]> > Reviewed-by: Chris Wilson <[email protected]> > --- > > Okay, here we go again. Page flip ioctl, this time, with blocking in > the kernel and optional events to userspace. Blocking in the kernel > doesn't hold any locks and lets other processes use the GPU while > we're > waiting for the flip to finish. > > cheers, > Kristian
Cool stuff! You have my Acked-by: Jakob Bornecrantz <[email protected]> if you fix a couple of things in the patch (mostly docu). Can you describes what happens if userspace continues to submit command to the pending buffer? Does it block, does the flip get delayed, or will it complete as soon as the commands that where pending at page_flip ioctl time? What happens if I try to use the old framebuffer as a source? What happens if I submit a new page_flip before the old one completes? Twenty questions I know but I just want what happens to be well documented, not just in this email thread but in actually source as well. So we can say "use the source Luke" with good conscience. Cheers Jakob. > > drivers/gpu/drm/drm_crtc.c | 69 ++++++++++ > drivers/gpu/drm/drm_drv.c | 1 + > drivers/gpu/drm/i915/i915_drv.h | 11 ++ > drivers/gpu/drm/i915/i915_gem.c | 63 +++++++++- > drivers/gpu/drm/i915/i915_irq.c | 10 ++ > drivers/gpu/drm/i915/i915_reg.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 232 +++++++++++++++++++++++++ > ++++----- > drivers/gpu/drm/i915/intel_drv.h | 3 + > include/drm/drm.h | 1 + > include/drm/drm_crtc.h | 8 ++ > include/drm/drm_mode.h | 11 ++ > 11 files changed, 378 insertions(+), 33 deletions(-) [SNIP] > > /** > * Device specific ioctls should only be in their respective headers > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index bfcc60d..7df8af2 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -290,6 +290,7 @@ struct drm_property { > struct drm_crtc; > struct drm_connector; > struct drm_encoder; > +struct drm_pending_vblank_event; > > /** > * drm_crtc_funcs - control CRTCs for a given device > @@ -333,6 +334,11 @@ struct drm_crtc_funcs { > void (*destroy)(struct drm_crtc *crtc); > > int (*set_config)(struct drm_mode_set *set); > + > + /* Flip to the given framebuffer on next vblank */ > + int (*page_flip)(struct drm_crtc *crtc, > + struct drm_framebuffer *fb, > + struct drm_pending_vblank_event *event); > }; The documentation here doesn't describe the stuff that is hard to get about the page_flip behavior. Like the blocking draw commands on the old framebuffer until the flip completes, that it should return immediate and so on. Please add that. > > /** > @@ -757,6 +763,8 @@ extern int drm_mode_gamma_get_ioctl(struct > drm_device *dev, > extern int drm_mode_gamma_set_ioctl(struct drm_device *dev, > void *data, struct drm_file > *file_priv); > extern bool drm_detect_hdmi_monitor(struct edid *edid); > +extern int drm_mode_page_flip_ioctl(struct drm_device *dev, > + void *data, struct drm_file > *file_priv); > extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev, > int hdisplay, int vdisplay, int > vrefresh, > bool reduced, bool interlaced, bool > margins); > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h > index 1f90841..bcabc17 100644 > --- a/include/drm/drm_mode.h > +++ b/include/drm/drm_mode.h > @@ -268,4 +268,15 @@ struct drm_mode_crtc_lut { > __u64 blue; > }; > Same here, can you please describe the side effects are of the ioctl? I know that none of the other ioctl's have this kind of docu, but my feeling is that we are in the get_resources does probe boat because of that, and I hate to see it again. Something like: /* * KMS page flip ioctl, providing cool tearfree flipping since 2009. * * Flips between to a new framebuffer at vblank time, the ioctl will * only schedule a flip and returns immediate. An event will be * generated if the PAGE_FLIP_EVENT flag is set, see ??????. * * Submitting a new page flip before the next one completes causes ??????. * * Side effects: * Page flip event generated if flag is provided. * Rendering to the old framebuffer is block untill completion of the flip, * that is the thread is blocked untill the page flip is completed. * Rendering to the new framebuffer is ?????. * Usage of either of the framebuffers as source is ?????. * Mapping the framebuffers ??????. (In general just describe the state of the framebuffers during the flip) * More side effects I can't think of right now, also happens. */ Something like that would help both people using it, people reviewing the code, and people implementing a driver. Thanks. > +#define DRM_MODE_PAGE_FLIP_EVENT 0x01 > +#define DRM_MODE_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_EVENT > + > +struct drm_mode_crtc_page_flip { > + __u32 crtc_id; > + __u32 fb_id; > + __u32 flags; > + __u32 reserved; > + __u64 user_data; > +}; > + > #endif > -- > 1.6.5.rc2 Cheers Jakob. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
