[Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
Jesse Barnes
jbarnes at virtuousgeek.org
Sat May 2 01:56:27 CEST 2009
On Sat, 2 May 2009 00:02:16 +0100
Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Fri, May 1, 2009 at 10:19 PM, Jesse Barnes
> <jbarnes at virtuousgeek.org> wrote:
> > On Wed, 29 Apr 2009 18:02:59 -0700
> > Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >
> >> On Wed, 29 Apr 2009 15:09:33 -0700
> >> Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >> > I'm still working through mutlihead issues on the kernel side;
> >> > the flip waits should wait for *both* vblank events before
> >> > completing the flip. But other than that, I'm pretty happy with
> >> > things.
> >>
> >> This incremental set fixes up the multihead handling and adds swap
> >> interval support as a bonus. It's nice to see flipping & no
> >> tearing on two heads at once!
> >
> > Here's an update that makes all the code generic. Jakob suggested
> > that we do the mode_set_base call out of the caller's context so we
> > don't block the caller waiting for the GTT domain transition
> > (effectively waiting until rendering finishes). I definitely want
> > to do this, but I'll have to add a way to communicate the necessary
> > flip data from the ioctl to the new work function.
>
> Cool stuff Jesse.
>
> I'm starting to agree with what Kristian said on irc, that we should
> only support one pending flip per crtc in the begining and then move
> onto supporting more later on if needed. I do think that the user
> space parts of libdrm looks fine with the exception of some comments.
>
> +#define DRM_IOCTL_GEM_PAGE_FLIP DRM_IOW( 0xB0, struct
> drm_gem_page_flip) Don't you mean DRM_IOCTL_MODE_PAGE_FLIP?
Yeah, should probably be _MODE_ instead.
> +#define DRM_PAGE_FLIP_WAIT (1<<0) /* block on
> previous page flip */ Isn't the comment wrong here?
Yep, this actually means 'wait for the queued flip to complete before
returning'.
> And if we go with the idea that we only support on pending flip,
> should we have some sort of flag to control if we should return -EBUSY
> or block until the pending flip has cleared and the flip and the
> calling flip has been added?
My initial intent was to block any subsequent flip calls if the
previous flip hasn't completed yet. The current code doesn't quite do
that though; it just makes sure there's no flip outstanding on the
buffer submitted. It would be easy enough to check the old_fb for
outstanding flips though too.
--
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list