Initial DRI3000 protocol specs available

[Keith Packard]

Owen Taylor <otaylor at redhat.com> writes:

> Sorry for joining the discussion late here. I went through the specs and
> discussion and have various comments and questions.

Thanks for reviewing stuff, of course. You're not late at all :-)

> * It would be great if we could figure out a plan to get to the
>   point where the exact same application code is going to work for
>   proprietary and open source drivers. When you get down to the details
>   of swap this isn't close to the case currently.

Agreed -- the problem here is that except for the nVidia closed drivers,
everything else implicitly serializes device access through the kernel,
providing a natural way to provide some defined order of
operations. Failing that, I'd love to know what mechanisms *could* work
with that design.

>   - Because swap handled client side in some drivers, INTEL_swap_event
>     is seen as awkward to implement.

I'm not sure what could be done here, other than to have some way for
the X server to get information about the swap and stuff it into the
event stream, of course. It could be as simple as having the client
stuff the event data to the X server itself.

>   - There is divergence on some basic behaviors, e.g.,  whether
>     glXSwapBuffers() glFinish() waits for the swap to complete or not.

glXSwapBuffers is pretty darn explicit in saying that it *does not* wait
for the swap to complete, and glFinish only promises to synchronize the
effects of rendering ("contents of the frame buffer"), not the actual
swap operation itself. I'm not sure how we're supposed to respond when
drivers ignore the spec and do their own thing?

>   - When rendering with a compositor, the X server is innocent of
>     relevant information about timing and when the application should
>     draw additional new frames. I've been working on handing this
>     via client <=> compositor protocols

With 'Swap', I think the X server should be involved as it is necessary
to get be able to 'idle' buffers which aren't in use after the
compositor is done with them. I tried to outline a sketch of how that
would work before.

> (https://mail.gnome.org/archives/wm-spec-list/2013-January/msg00000.html)
>
>     But this adds a lot of complexity to the minimal client, especially
>     when a client wants to work both redirected and unredirected.

Right, which is why I think fixing the X server to help here would be better.

>   I think it would be great if we could sit down and figure out what
>   the Linux-ecosystem API is for this in a way we could give to
>   application authors.

Ideally, a GL application using simple GLX or EGL APIs would work
'perfectly', without the need to use additional X-specific APIs. My hope
with splitting DRI3000 into separate DRI3 and Swap extensions is to
provide those same semantics to simple double-buffered 2D applications
using core X and Render drawing as well, without requiring that they be
rewritten to use GL, and while providing all of the same functionality
over the network as local direct rendering applications get today.

> * One significant problem that I have currently is that the default mode
>   for the Intel drivers is to use triple buffering and send back swap
>   events *when rendering the next frame would not block* - that is,
>   immediately. This results in a frame of unnecessary latency.
>   (The too-early events are also missing ust/msc/sbc information.)

As you noted, there are a whole range of suitable times to tell clients
about their buffers:

 1) Right after the swap, the client needs to know what happened to each
    buffer and what the scheduled swap time is.

 2) When the buffer usage changes; for DRI2, that's what the Invalidate
    events are for. With DRI3 as proposed, that's what the reply to the
    SwapRegion contains.

 3) When their contents actually appear on the screen.

I suggest that we'll need all three to provide applications enough
information to make good drawing choices.

>   The SwapComplete event is specified as - "This event is delivered
>   when a SwapRegion operation completes" - but the specification
>   of SwapRegion itself is fuzzy enough that I'm unclear exactly what
>   that means.
>
>   - The description SwapRegion needs to define "swap" since the
>     operation has only a vague resemblance to the English-language
>     meaning of "swap".

Right, SwapRegion can either be a copy operation or an actual swap. The
returned information about idle buffers tells the client what they
contain, so I think the only confusion here is over the name of the request?

>   - My interpretation of SwapRegion is that the actual propagation of
>     source to destination is *asynchronous* to the X protocol stream.
>     This is implied by "Schedule a swap..." but probably should be
>     explicitly stated, since it is radically different from other
>     rendering in X.

Ok, a bit more wording clarifying the inherent asynchronous nature of
the Swap operation seems necessary.

>   - Is the serial in the SwapComplete event synchronous to the protocol
>     stream? E.g., can you assume that any CopyArea from the destination
>     drawable before that serial will get the old contents, and a
>     CopyArea from the destination after that serial will get the new
>     contents?

No (and this needs to be clarified). The SwapComplete event marks the
point at which the swap actually occurred; CopyArea requests with
sequence numbers before that in the SwapComplete event will use the old
contents, CopyArea requests with sequence numbers after that in the
SwapComplete event will use the new contents.

>   - What happens when multiple SwapRegion requests are made with a
>     swap-interval of zero. Are previous ones discarded?

Any time a SwapRegion request is made with one still pending, the server
may choose to skip the first contents and swap directly to the second
contents. I'm not sure how this would be visible to the application
though?

>   - Is it an error to render to a non-idle pixmap? Is it an error to
>     pass a non-idle pixmap as the source to SwapRegion?

No.

>   - What's the interaction between swap-interval and target-msc, etc?

I'm afraid I just copied these from the DRI2 spec without really
understanding the precise semantics. They originally came from the
related GL specs.

>   - When a window is redirected, what's the interpretation of 
>     swap-interval, target-msc, etc? Is it that the server performs the
>     operation at the selected blanking interval (as if they window
>     wasn't redirected), and then damage/other events are generated
>     and the server picks it up and renders to the real front buffer
>     at the next opportunity - usually a frame later.

This sends us down a very deep hole, and one which I intend to resolve
at some point, but for now, I'd love to focus on getting the semantics
for non-redirected windows looking sane, and then try to figure out how
to replicate those semantics in a redirected world.

In particular, the compositor needs to be involved in scheduling the
final swap and notifying applications when those have happened.

> * Do I understand correctly that the idle pixmaps returned from
>   a SwapRegion request are the pixmaps that *will* be idle once the
>   corresponding SwapComplete event is received?

No, the pixmaps returned in SwapRegion are those which are idle when the
SwapRegion request itself completes. Through a long discussion which
I've already posted, that means we'll end up triple buffering all
applications, so I'm designing an event-based scheme that will avoid
this.

> * In the definition of SWAPIDLE you say:
>
>     If valid is TRUE, swap-hi/swap-lo form a 64-bit
>     swap count value from the SwapRegion request which matches the
>     data that the pixmap currently contains
>
>  If I'm not misunderstanding things, this is a confusing statement
>  because, leaving aside damage to the front buffer, pixmaps always
>  contain the same contents (whatever the client rendered into it.)

No, the Swap operation may actually *replace* the pixmap contents with
the other buffer contents. That allows for efficient pointer swapping
instead of actual data copying. This number lets the client know what
the pixmap holds as a result of this operation, which may simply be the
previous pixmap contents or may be the contents from one or more frames
previous.

>  Is the use of the swap-hi/swap-lo identify the SwapRegion problematical
>  in the case where swaps aren't throttled? Would it be better to use
>  sequence number of the request? Or is the pixmap itself sufficient?

We need a simple count; perhaps sequence numbers would suffice, but
certainly pixmap IDs won't.

> * What control, if any, will applications have over the number of
>   buffers used - what the behavior will be when an application starts
>   rendering another frame in terms of allocating a new buffer versus
>   swapping?

The application is entirely in charge of allocating buffers; the server
never allocates anything. As such, the application may well choose to
pause until buffers go idle before continuing to render so as to limit
buffer use to a sane amount.

Switching to events for Idle notification should make this a lot logical
and perhaps easier to understand, although the client implementation
will be a pain.

> * Do we need to deal with stereo as part of this?

Probably? But I'm not sure how?

-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130228/33d70ee7/attachment-0001.pgp>