[Mesa-dev] [PATCH 06/11] loader_dri3: Honour the request to preserve back buffer content

[Michel Dänzer]

On 15/08/17 09:45 PM, Thomas Hellstrom wrote:
> On 08/15/2017 09:33 AM, Michel Dänzer wrote:
>> On 11/08/17 11:14 PM, Thomas Hellstrom wrote:
>>> EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc()
>>> to indicate
>>> that it wants to preserve back buffer contents across a buffer swap.
>>>
>>> While the loader then turns off server-side page-flipping there's
>>> nothing to
>>> guarantee that a new backbuffer isn't chosen when EGL starts to
>>> render again,
>>> and that buffer's content is of course undefined.
>>>
>>> So rework the functionality:
>>> If the client supports local blits, allow server-side page flipping
>>> and when
>>> a new back is grabbed, if needed, blit the old back's content to the
>>> new back.
>>> If the client doesn't support local blits, disallow server-side
>>> page-flipping
>>> to avoid a client deadlock and then, when grabbing a new back buffer,
>>> sleep
>>> until the old back is idle, which may take a substantial time
>>> depending on
>>> swap interval.
>>>
>>> Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
>> [...]
>>
>>> @@ -475,12 +476,21 @@ dri3_find_back(struct loader_dri3_drawable *draw)
>>>      int b;
>>>      xcb_generic_event_t *ev;
>>>      xcb_present_generic_event_t *ge;
>>> +   int num_to_consider = draw->num_back;
>>>        /* Increase the likelyhood of reusing current buffer */
>>>      dri3_flush_present_events(draw);
>>>   +   /* Check whether we need to reuse the current back buffer as
>>> new back.
>>> +    * In that case, wait until it's not busy anymore.
>>> +    */
>>> +   if (!draw->have_image_blit && draw->cur_blit_source != -1) {
>>> +      num_to_consider = 1;
>>> +      draw->cur_blit_source = -1;
>>> +   }
>> Is it possible that dri3_find_back gets called with
>> draw->cur_blit_source != -1, entering this block (assuming
>> !draw->have_image_blit)...
>>
>>
>>>      for (;;) {
>>> -      for (b = 0; b < draw->num_back; b++) {
>>> +      for (b = 0; b < num_to_consider; b++) {
>>>            int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) %
>>> draw->num_back);
>>>            struct loader_dri3_buffer *buffer = draw->buffers[id];
>> ... Then later gets called again with draw->cur_blit_source == -1,
>> choosing a different back buffer here, because the previous one is still
>> busy?
>>
>>
> I don't think that's possible. If dri3_find_back returns a back buffer,
> it should be idle, in the sense that it's not currently in the swap
> chain or being scanned out from. It may still have a non-signaled fence
> though. If a later call to dri_find_back() decides it's busy then
> someone must have called swapBuffer in between and it's time to change
> back anyway...

Okay, then this patch is also

Reviewed-by: Michel Dänzer <michel.daenzer at amd.com>


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer