[Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)

[Jesse Barnes]

On Mon, 04 May 2009 14:45:07 -0700
Ian Romanick <idr at freedesktop.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jesse Barnes wrote:
> > Ok, this set addresses all the shortcomings of the last set, and
> > things seem quite solid, aside from output detection on my test
> > platform which causes me to wait on flips from pipes with no
> > outputs attached.  Note that this meant changing the locking
> > semantics for the set_pipe_base call to avoid racing between the
> > base update and getting a seqno for the vblank wait.
> > 
> > Dave & Jakob suggested possibly making the ioctl KMS generic.  I
> > think this might be possible, but I'd appreciate review of it to
> > make sure the interfaces look ok, since I'd like to push this out
> > soon (this week if possible).
> > 
> > This one still uses the setBuffers call, but I kind of like it now
> > that I've worked with it more.  It makes the DRI driver a little
> > cleaner (separating actual buffer acquisition from renderbuffer
> > updates), but I'm still open to better ways of doing it that don't
> > involve a bunch more round trips.
> > 
> > Overall, this patchset adds a new ioctl to the kernel,
> > DRM_I915_GEM_PAGE_FLIP, with two flags, I915_PAGE_FLIP_WAIT and
> > I915_PAGE_FLIP_ASYNC.  PAGE_FLIP_WAIT will block the return of the
> > ioctl until the flip completes (useful for throttling perhaps),
> > while PAGE_FLIP_ASYNC queues the flip immediately and doesn't wait
> > for any outstanding flips to finish.
> > 
> > The ioctl is exposed in libdrm as drm_intel_flip_bufs().  New DRI2
> > protocol is added to send swapbuffers requests to the server from
> > DRI clients.  The server and AIGLX clients call into the driver
> > directly, and update client buffers with the returned value.
> > 
> > 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.
> > 
> > I'm attaching them this time because I don't want to send a ton of
> > mail again.
> 
> There's a problem in dri2SwapBuffers.  If a new libGL is used with an
> old driver, psc->dri2->setBuffers won't be set, right?

Yes.  I should probably add an #ifdef for that like ->flush has.

> Also, should there be a mechanism for the 3D driver to force swap
> buffers to be implemented with a copy?

Hm, well the 2D driver can easily force it by not implementing a
swapbuffers function or by returning NULL, but I guess allowing the 3D
driver to force it would be ok to.  Could probably just check for
->setbuffers?  Or maybe add a way for the driver to set the
swapAvailable flag...

-- 
Jesse Barnes, Intel Open Source Technology Center