[Mesa-dev] [PATCH] glx: Handle out-of-sequence swap completion events correctly. (v2)

[Emil Velikov]

On 12/03/15 19:34, Mario Kleiner wrote:
> The code for emitting INTEL_swap_events swap completion
> events needs to translate from 32-Bit sbc on the wire to
> 64-Bit sbc for the events and handle wraparound accordingly.
> 
> It assumed that events would be sent by the server in the
> order their corresponding swap requests were emitted from
> the client, iow. sbc count should be always increasing. This
> was correct for DRI2.
> 
> This is not always the case under the DRI3/Present backend,
> where the Present extension can execute presents and send out
> completion events in a different order than the submission
> order of the present requests, due to client code specifying
> targetMSC target vblank counts which are not strictly
> monotonically increasing. This confused the wraparound
> handling. This patch fixes the problem by handling 32-Bit
> wraparound in both directions. As long as successive swap
> completion events real 64-Bit sbc's don't differ by more
> than 2^30, this should be able to do the right thing.
> 
> How this is supposed to work:
> 
> awire->sbc contains the low 32-Bits of the true 64-Bit sbc
> of the current swap event, transmitted over the wire.
> 
> glxDraw->lastEventSbc contains the low 32-Bits of the 64-Bit
> sbc of the most recently processed swap event.
> 
> glxDraw->eventSbcWrap is a 64-Bit offset which tracks the upper
> 32-Bits of the current sbc. The final 64-Bit output sbc
> aevent->sbc is computed from the sum of awire->sbc and
> glxDraw->eventSbcWrap.
> 
> Under DRI3/Present, swap completion events can be received
> slightly out of order due to non-monotic targetMsc specified
> by client code, e.g., present request submission:
> 
> Submission sbc:   1   2   3
> targetMsc:        10  11  9
> 
> Reception of completion events:
> Completion sbc:   3   1   2
> 
> The completion sequence 3, 1, 2 would confuse the old wraparound
> handling made for DRI2 as 1 < 3 --> Assumes a 32-Bit wraparound
> has happened when it hasn't.
> 
> The client can queue multiple present requests, in the case of
> Mesa up to n requests for n-buffered rendering, e.g., n =  2-4 in
> the current Mesa GLX DRI3/Present implementation. In the case of
> direct Pixmap presents via xcb_present_pixmap() the number n is
> limited by the amount of memory available.
> 
> We reasonably assume that the number of outstanding requests n is
> much less than 2 billion due to memory contraints and common sense.
> Therefore while the order of received sbc's can be a bit scrambled,
> successive 64-Bit sbc's won't deviate by much, a given sbc may be
> a few counts lower or higher than the previous received sbc.
> 
> Therefore any large difference between the incoming awire->sbc and
> the last recorded glxDraw->lastEventSbc will be due to 32-Bit
> wraparound and we need to adapt glxDraw->eventSbcWrap accordingly
> to adjust the upper 32-Bits of the sbc.
> 
> Two cases, correponding to the two if-statements in the patch:
> 
> a) Previous sbc event was below the last 2^32 boundary, in the previous
> glxDraw->eventSbcWrap epoch, the new sbc event is in the next 2^32
> epoch, therefore the low 32-Bit awire->sbc wrapped around to zero,
> or close to zero --> awire->sbc is apparently much lower than the
> glxDraw->lastEventSbc recorded for the previous epoch
> 
> --> We need to increment glxDraw->eventSbcWrap by 2^32 to adjust
> the current epoch to be one higher than the previous one.
> 
> --> Case a) also handles the old DRI2 behaviour.
> 
> b) Previous sbc event was above closest 2^32 boundary, but now a
> late event from the previous 2^32 epoch arrives, with a true sbc
> that belongs to the previous 2^32 segment, so the awire->sbc of
> this late event has a high count close to 2^32, whereas
> glxDraw->lastEventSbc is closer to zero --> awire->sbc is much
> greater than glXDraw->lastEventSbc.
> 
> --> We need to decrement glxDraw->eventSbcWrap by 2^32 to adjust
> the current epoch back to the previous lower epoch of this late
> completion event.
> 
> We assume such a wraparound to a higher (a) epoch or lower (b)
> epoch has happened if awire->sbc and glxDraw->lastEventSbc differ
> by more than 2^30 counts, as such a difference can only happen
> on wraparound, or if somehow 2^30 present requests would be pending
> for a given drawable inside the server, which is rather unlikely.
> 
> v2: Explain the reason for this patch and the new wraparound handling
>     much more extensive in commit message, no code change wrt. initial
>     version.
> 
> Cc: "10.3 10.4 10.5" <mesa-stable at lists.freedesktop.org>
> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
Thanks for keeping up Mario !

Planning to commit this (with Michel's r-b) tomorrow morning unless
there are any objections/comments.

-Emil