Initial DRI3000 protocol specs available

[Aaron Plattner]

On 03/06/2013 10:35 PM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> Owen Taylor <otaylor at redhat.com> writes:
>
>> A complex scheme where the compositor and the server collaborate on the
>> implementation of SwapRegion seems fragile to me, and still doesn't get
>> some details right - like the swap count returned from SwapRegion.
>>
>> What if we made SwapRegion redirectable along the lines of
>> ResizeRedirectMask? Since it would be tricky to block the client calling
>> SwapRegion until the compositor responded, this would probably require
>> removing the reply to SwapRegion and sending everything needed back in
>> events.
>
> When I first read this a week ago, I thought this was a crazy plan; but
> upon reflection, I think this is exactly the right direction. I've
> written up a blog posting in more detail about that here:
>
>          http://keithp.com/blogs/composite-swap/
>
>>   SwapScheduled - whatever information is available immediately on
>>                   receipt of SwapRegion
>
> I think this can still be in the reply to SwapRegion itself; essentially
> all we're returning is the swap-hi/swap-lo numbers and a suggestion for
> future buffer allocation sizes. We could place the buffer size hints in
> a separate event, but I don't think they're that critical; it's just a
> hint, and we'll get it right after a couple of swaps once the user stops
> moving the window around anyways.
>
>>   SwapIdle      - a buffer is returned to the application for rendering
>>   SwapComplete  - the swap actually happened and we know the
>>                   msc/sbc/ust triple
>
> Yup. The blog posting suggests how the Complete event might be delayed
> until the Compositor gets the content up onto the screen itself.

If I'm understanding this correctly, this requires the X server to 
receive a notification from the GPU that the swap is complete so it can 
send the SwapComplete event.  Is there any chance this could be done 
with a Fence instead?  The application could specify the fence in the 
Swap request, and then use that fence to block further rendering on the 
GPU or wait on the fence from the CPU.  We typically try to do the 
scheduling on the GPU when possible because triggering an interrupt and 
waking up the X server burns power and adds latency for no good reason.

> I also think that SwapIdle should *not* be an event. Instead, the client
> should mark its pixmap as 'becomes idle upon swap'; on redirection, the
> compositor ends up holding the last 'its not idle yet' bit, and when it
> does the 'becomes idle upon swap', then the buffer goes idle.
>
> The client must then tell the server to un-idle the pixmap, and that
> request will return whether the contents were preserved or not. This has
> to be synchronous or huge races will persist.
>
>> But I don't know that you need that much granularity. I think SwapIdle
>> and SwapComplete are sufficient.
>
> As above, SwapIdle isn't good enough, an explicit un-idle request is required.
>
>> Tricky parts:
>>
>>   * Not leaking buffers during redirection/unredirection could be tricky.
>>     What if the compositor exits while a client is waiting for a
>>     SwapIdle? An event when swap is redirected/unredirected is probably
>>     necessary.
>
> When the Compositor exits, the X server will know all of the pending
> SwapRegion requests and can 'unredirect' them easily enough.
>
> I don't want to tell apps when they're getting redirected/unredirected,
> and I don't think it's necessary.
>
>>   * To make this somewhat safe, the concept of "idle" has to be one of
>>     correct display not system stability. It can't take down the system
>>     if the compositor sends SwapIdle at the wrong time.
>
> See above.
>
>>   * Because the SBC is a drawable attribute it's a little complex to
>>     continue having the right value over swap redirection.
>>
>>      When a window is swap-redirected, we say that the SBC is
>>      incremented by one every time the redirecting client calls
>>      SwapRegion, and never otherwise. A query is provided for the
>>      current value.
>
> We could simply decouple these values and just have a 'swap count'
> associated with the window which is used to mark pixmap contents when
> 'UnIdled'.
>
>>   * It doesn't make sense to have both the server and the compositor
>>     scheduling stuff. I think you'd specify that once you swap
>>     redirect a window, it gets simple:
>
> Good point. The redirected swap event should contain all of the swap
> parameters so that the Compositor can appropriately schedule the window
> swap with the matching screen swap.
>
>>     Actually, from the compositor's perspective, the window's front
>>     buffer doesn't matter, but you probably need to keep it current
>>     to make screenshot tools, etc, work correctly.
>
> My swap redirect plan has that pixmap getting swapped at the same time
> the screen pixmap is swapped, so things will look 'right'.
>
>> Is this better than a more collaborative approach where the server and
>> compositor together determine what pixmaps are idle?
>
> Idleness is certainly a joint prospect, but I don't think it's
> cooperative. Instead, a pixmap is idle when both application and
> compositor say it is idle. The SwapRedirect explicitly marks the pixmap
> as 'not idle' for the compositor, and an explicit 'make it idle' call is
> required by the compositor.
>


-- 
Aaron