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

[Kristian Høgsberg]

On Tue, May 5, 2009 at 2:34 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Tue, 05 May 2009 11:24:29 -0700
> Ian Romanick <idr at freedesktop.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Kristian Høgsberg wrote:
>> > On Tue, May 5, 2009 at 12:20 PM, Jesse Barnes
>> > <jbarnes at virtuousgeek.org> wrote:
>> >> On Mon, 04 May 2009 19:14:29 -0700
>> >> Ian Romanick <idr at freedesktop.org> wrote:
>> >>
>> >>> Having this ability would allow us to advertise some fbconfigs
>> >>> with GLX_SWAP_METHOD_OML = GLX_SWAP_COPY_OML.  We obviously don't
>> >>> have any apps that use that today, but I can think of a couple
>> >>> that should. :)
>> >> Yeah, ok.
>> >
>> > It's not something that needs to be exposed in the protocol or dri2
>> > module.  If you want the copy behaviour, use DRI2CopyRegion().
>> > Another point about GLX_SWAP_METHOD_OML is that we can't really
>> > implement the "always swap" (GLX_SWAP_EXCHANGE_OML) behaviour
>> > without a fair bit of yucky code, and without that we can't really
>> > claim to support the extension.
>>
>> I think you misunderstand the extension.  The fbconfig has an extra
>> value that says "this is how glXSwapBuffer happens."  The three
>> possible values are: flip, copy, unknown.  Right now we support this
>> extension, but we always say unknown.  As you point out, I doubt we'd
>> ever be able to say flip, but we might be able to say copy and
>> unknown.  Telling the application flip isn't terribly useful, but a
>> lot of applications could do something smart (i.e., partial screen
>> updates) if they knew the swap method was always copy.  Right?
>
> Actually I think we could do flip as well, depending on the expected
> semantics.  If all apps had fake front buffers (i.e. private back
> *and* front buffers), we could simply exchange those two at swapbuffers
> time.  That assumes a reasonably intelligent compositing manager
> though; we wouldn't want to immediately follow any swap by a copy to
> the real front buffer or there'd be no benefit.  However if the
> compositing manager was responsible for copying all the fake fronts to
> the real front if swaps had occurred it could be a win in terms of
> consumed bandwidth and swap latency (I think Wayland does it this way?).

I wayland page flipping/copying, double, triple or n-buffering is all
client side decisions.  Wayland only knows about the front buffer
(which doesn't have child windows or other cliprects), all the other
buffers are managed by the client.  The client can do page flipping by
passing attaching a new buffer handle to the surface or copy (all or
regions) from a temp/back buffer to the wayland surface.  How many
buffers to keep around and whether or when to block rendering is up to
the client.

> On X, we unfortunately always have to do the copy to the front buffer,
> though we could probably get smarter about the frequency.

The main reason we can't easily promise flipping under X is child
windows and clip-rects.  We could fake it by copying back the dirty
regions from the new front to the back just after the flip, at that
point it's not really worthwhile anymore, and definitely too complex.

cheers,
Kristian