2009/11/12 Jakob Bornecrantz <[email protected]>:
> 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.
Cool, thanks. Good points, I'll update the patch with documentation
as you suggest.
cheers,
Kristian
>> 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
