Initial DRI3000 protocol specs available

[Ian Romanick]

On 02/26/2013 01:01 PM, Owen Taylor wrote:
> Sorry for joining the discussion late here. I went through the specs and
> discussion and have various comments and questions.
>
> - Owen
>
> * 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.
>
>    - Because swap handled client side in some drivers, INTEL_swap_event
>      is seen as awkward to implement.
>
>    - There is divergence on some basic behaviors, e.g.,  whether
>      glXSwapBuffers() glFinish() waits for the swap to complete or not.
>
>    - 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
>
> (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.
>
>    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.
>
> * 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.)
>
>    So I'd like to make sure that we know exactly what SwapComplete means
>    and not have creative reinterpretations based on what works well
>    for one client or another.
>
>    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".

Maybe call it PresentRegion instead?  Swap is another one of those 
overloaded terms in graphics.  It's not quite as bad as "normal," but 
it's pretty close.

>    - 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.
>
>    - 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?
>
>    - What happens when multiple SwapRegion requests are made with a
>      swap-interval of zero. Are previous ones discarded?
>
>    - 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?
>
>    - What's the interaction between swap-interval and target-msc, etc?
>
>    - 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.
>
> * 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?
>
>    If this is correct, what happens if things change before the swap
>    actually happens and what was scheduled as a swap ends up being
>    a copy? Is it sufficient to assume that a ConfigureNotify on a
>    destination window means that all pixmaps passed to previous
>    SwapRegion requests are now idle?
>
> * 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.)
>
>   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?
>
> * 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?
>
> * Do we need to deal with stereo as part of this?
>
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>