Initial DRI3000 protocol specs available

[Owen Taylor]

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".

  - 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?